PHOTOGRAPH  THIS  SHEET 


!>• 

<M  g 

1 


INVENTORY 


|  LEVEL  5'  e<-  Co  INV™  ORY 

1  f  ..  Lilftk  .  , 

|  TtfKN*.  UR-  Ffh^l  #  Jc/^c  [47? 

%  N*mh$Q\jfcc£N  77-  C  -OAEJ--00O/  v.& 

U  »  nnriTMEMT  insNTicir  atiam 


DOCUMENT  IDENTIFICATION 


DISTRIBUTION  STATEMENT  A 


Approved  for  public  release] 
Distribution  Unlimited 


DISTRIBUTION  STATEMENT 


ACCESSION  FOR 


NT1S  CRAAI 

DTK.'  TAB 

UNANNOUNCED 
JUSTIFICATION 


BY 


DISTRIBUTION  / 


AVAILABILITY  CODES 


AVAIL  AND/OR  SPECIAL 


s 


DTIC 

FLECTE 


NOV  10  1980 


DATE  ACCESSIONED 


DISTRIBUTION  STAMP 


80  10  28  05 


DATE  RECEIVED  IN  DTIC 

PHOTOGRAPH  THIS  SHEET  AND  RETURN  TO  DT1C-DDA-2 


DOCUMENT  PROCESSING  SHEET 


Report  No:  NAVTRAEQUIPCEN  77-C-0185-0001 
LR-895 


DESIGN  DEFINITION  STUDY  REPORT 

FULL  CREW  INTERACTION  SIMULATOR-LABORATORY  MODEL 
(DEVICE  X17B7) 

VOLUME  VI  -  TRAINING  SYSTEMS 

Link  Division,  The  SINGER  COMPANY 
Binghamton,  New  York  13902 


FINAL 
June  1978 


POD  Distribution  Statement 

Approved  for  public  release; 
Distribution  unlimited. 


Government  Rights  in  Data  Statement 

Reproduction  of  this  publication  in 
whole  or  in  part  is  permitted  for 
any  purpose  of  the  United  States 
Government. 


Prepared  for: 

NAVAL  TRAINING  EQUIPMENT  CENTER 
Orlando,  Florida  32813 


80  10  28  055 


UNCLASSIFIEn 


SECURITY  CLASSIFICATION  OF  Thi*  PAOE  flWin  Polo  Entered) 


REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

1.  MWJlT  NUMllA  2.  OOVT  ACCESSION  NO. 

NAVTRAEQUIPCEN  77-C-0185-0001 

t.  RECIPIENT'S  CAT  AV.OO  NUMBER 

A.  TITLE  (end  tubtltlo)  1 

DESIGN  DEFINITION  STUDY  REPORT 

FULL  CREW  INTERACTION  SIMULATOR-LAB.  MODEL 
! (DEVICE  X17B7) 

i 

I.  TVPC  OF  REPORT  *  PERIOD  COVCRCO 

Final 

June  1978 

1.  PCRFORMINO  ONO.  REPORT  NUMBER 

LR-895 

V.  AUTHOR?*) 

t.  CONTRACT  OR  ORANT  HUMBERfaJ 

N61339-77-C.Q185 

*.  PCRFORMINO  OROANIEATION  N  AM t  ANO  ADDRESS 

Link  Division,  The  SINGER  COMPANY 
Binghamton,  New  York  13902 

10.  PROORAM  ELEMENT.  PROJECT.  TASK 
AREA  A  WORK  UNIT  NUMBERS 

II.  CONTROLLINO  OFFICE  N  AMI  ANO  AOORSSS 

NAVAL  TRAINING  EQUIPMENT  CENTER 

Orlando,  Florida  32813 

12.  REPORT  DATE 

June  1978 

IS.  number  of  paces 

'l*.  MONlTONINO  AoInCY  name  a  AODRESSfll  dllleront  from  Controlling  Olll  ce) 

It-  SECURITY  CLASS,  (el  title  report) 

UNCLASSIFIED 

41a.  OECLASSIFICATION/OOWNORAOINO 
SCHEDULE  N/A 

It.  DISTRIBUTION  tTATCMCNT  (of  Ala  Report) 

(Approved  for  public  release;  Distribution  unlimited 

17.  DltTNlOUTlON  tTATCMCNT  (of  die  ehrtrect  entered  In  Block  30,  II  different  horn  Naps rt) 

Report  consists  of  twelve  sections  bound  in  7  volumes. 

ft.  KC Y  VONDt  fCaaNmt  an  roeeree  alps  If  neeeeeerr  tnd  Identity  hr  Mss*  number) 

i 

St.  AMT  RAC  T  (CmHnm  m  mvith  «l#f  It  Ifniltf  by  blpck  number) 

» 

i 

0®  uw»  M7J  KOfTlOM  OF  1  NOV  ••  It  OBSOLETE 


.  - UNCLASSIFIED _ 

ItCUNirr  CLASSIFICATION  OF  this  PACE  (Whtn  Dote  Entered) 


TABLE  OF  CONTENTS 


SECTION 


11. 


11.1 

11.1.1 

11.1.1 

11.1.1 

11.1.1 

11.1.1 

11.1.1 

11.1.1 

11.1.2 

11.1.3 

11.1.3 

11.1.3 

11.1.3 

11.1.4 
11.1.4 
11.1.4 
11.1.4 
11.1.4 
11.1.4 
11.1.4 

11.1.4 

11.1.5 
11.1.5 

11.1.5 

11.1.6 
11.1.6 
11.1.6 
11.1.7 
11.1.7 

11.1.7 

11.1.7 

11.1.7 

11.1.7 

11.2 

11.2.1 

11.2.2 

11.2.2 

11.2.3 


VOLUME  XI 


TITLE  PAGE 


TRAINING  SYSTEMS  STUDY  AND  CONCEPT  11-1 

FORMULATION  . 

Instructional  Systems  .  11-1 

Instructor  Requirements  11-1 

.1  Simulated  Tank  Systems  11-1 

. 2  Simulated  Operating  Environment  .  11-2 

.3  Advanced  Training  Features  .  11-3 

.4  Crew  Performance  Monitoring  and  Evaluation  .  11-4 

.5  Additional  Control-Display  Requirements  .  .  .  11-5 

.  6  Locus  and  Manning . 11-6 

Experimental  Requirements  .  11-6 

Instructor  Station  .  11-8 

.1  Instructor  Driving  Provisions  .  11-8 

.2  Vehicle  Position  Chart  (VPC)  .  11-10 

.  3  Instructor/Experimenter  Display . 11-12 

Instructional  Features  .  11-16 

.1  Problem  Formulation  and  Control  .  11-16 

.2  Record/Playback . 11-19 

.3  Performance  Monitoring  .  11-21 

.4  Briefing/Debriefing  .  11-26 

.5  Demonstrations  . . 11-27 

.6  Scoring  . . 11-27 

.7  Record/Playback  Audio  .  11-28 

System  Design  Tradeoff  and  Selection  ....  11-29 

.1  Display  System . 11-29 

.2  Record/Playback . 11-30 

Instructor  Station  Configuration  .  11-30 

.1  Instructor  Observation  Stations  .  11-30 

.2  Main  Instructor/Experimenter  Station  ....  11-35 

Instructional  Features  .  11-37 

.1  Instructor  and  Experimenter  Control/ 

Display  Medium  .  11-37 

.2  Malfunctions . 11-41 

.3  Record/Playback . 11-4  3 

.4  Problem  Formulation  and  Control  .  11-43 

.5  Performance  Monitoring  and  Scoring  .  11-47 

Computational  Systems  .  11-52 

Computation  System  Accuracy  and  Resolution.  .  11-52 

Computation  Software  .  11-53 

.  2  Higher  Order  Languages . 11-54 

Computer  Resource  Requirements  .  11-55 


11.2.3.1  Computation  Speed  .  11-57 

11.2.4  Computer  Peripheral  Requirements  .  11-59 

11.2.5  Computer  Program  Requirements  .  11-59 

11.2.5.1  Software  Design  Approaches  .  11-59 

11.2.5.2  Programming  Language  .  11-60 

11.2.5.3  Real-Time  Programs  .  11-60 

11.2.5.4  Off-Line  Programs  .  11-61 

11.2.6  Computer  Selection  .  11-62 

11.2.7  Performance  .  11-65 

11.2.7.1  Central  Processors  .  11-65 

11.2.7.2  Memory  Systems  .  ...  11-68 

11.2.7.3  Shared  Peripherals  .  11-68 

11.2.7.4  Special  Function  Interfaces  .  11-78 

11.2.7.5  Signal  Conversion  Equipment  .  11-78 

11.2.8  FCIS-LM  Computer  Program  Development  ....  11-82 

11.2.8.1  Program  Module  Architecture  .  11-83 

11.2.8.2  Program  Language  .  11-83 

11.2.8.3  Real-Time  Computer  Program  Requirements  .  .  .  11-83 

11.2.8.4  Off-Line  Programs  .  11-88 


LIST  OF  ILLUSTRATIONS 
VOLUME  VI 


NUMBER  TITLE  PAGE 

11-1  Typical  System  Status  Page . 11-9 

11-2  FCIS-LM  Driver  Station  Instructor/Observer 

Position . 11-33 

11-3  FCIS-LM  Fighting  Station  Instructor/Observer 

Position . 11-34 

11-4  FCIS-LM  Instructor/Experimenter  Station.  .  .  .  11-36 

11-5  FCIS-LM  Instructor /Experimenter  Display 

System  (Example  1)  .  . . 11-38 

11-6  FCIS-LM  Instructor/Experimenter  Display 

System  (Example  2) . ' . 11-39 

11-7  Typical  CRT  Page  Generation  Mode  Format.  .  .  .  11-40 

11-8  Re-ganaratad  CRT  Page  Display . 11-41 

11-9  Preprogramming  Structure . 11-45 

11-10  Typical  Scoring  Display . 11-49 

11-11  Performance  Monitoring-Start  of  Engagement 

(Flow  Chart) . 11-51 

11-12  FCIS-LM  Computer  Complex . 11-68 

11-13  Digital  Remote  Control  Unit . 11-78 

11-14  Real-Time  Interface  System  Block  Diagram.  .  .  . 11-84 


LIST  OF  TABLES 
VOLUME  VI 


NUMBER  TITLE  PAGE 

11-1  Display/Control  Requirements . 11-14 

11-2  Scenario  Index . 11-22 

11-3  Trade-Off  Chart  -  Displays.  . . 11-31 

11-4  Trade-Off  Chart  -  Record/Playback . 11-32 

11-5  Digital  Computational  System  Evaluation 

Criteria . . 11-56 

11-6  FCIS-LM  Computer  Real-Time  Memory  Requirements.  .11-58 

11-7  Computer  Off-Line  and  Background  Memory 

Requirements . 11-58D 

11-8  FCIS  Disk  Loading  Requirements . 11-58E 

11-9  Instruction  Mix  and  Instruction  Time  Comparison 

Interdata . 11-66 

11-10  Instruction  Set . 11-71 

11-11  DMA  Data  Format  Conversions . 11-83A 

11-12  SCE  Requirements . .11-83A 


SECTION  XI 


11.  TRAINING  SYSTEMS  STUDY  AND  CONCEPT  FORMULATION 

Training  systems  comprise  those  systems  that  are  not  associated 
with  direct  simulation  of  the  vehicle  or  the  environment,  but 
are  needed  to  complete  the  total  trainer  requirement.  They 
include : 

o  Trainer  Power  System 

o  Trainer  Maintenance  System 

o  Trainer  Instructional  System 

o  Trainer  Computational  System 

Of  these,  only  the  trainer  instructional  and  computational 
systems  require  extensive  study  to  formulate  a  design  approach 
for  the  FCIS-LM  device. 

11.1  Instructional  System 

11.1.1  Instructor  Requirements.  Instructor  tasks  involve 
the  following  basic  functions: 

a.  Initializing  and  controlling  training  exercises 

b.  Monitoring  and  evaluating  trainee  (crew)  performance 

c.  Modifying  the  training  exercise,  as  necessary 

d.  Briefing  and  debriefing  trainees  (crews) 

e.  Collecting,  controlling  data  and  setting  up  experiments 
to  be  performed  in  the  simulator. 

The  M60A3  Task  Analysis  and  resultant  Training  Requirements 
Analysis  and  Experimental  Requirements  Analysis  (Sections 
4,  5,  and  6)  form  the  basis  from  which  instructor  loads,  man¬ 
ning,  display  and  control  requirements  are  derived.  Those 
monitoring, control  and  evaluation  functions  which  are  impos¬ 
sible,  inappropriate  or  not  cost  effective  to  automate,  will 
be  assigned  to  the  instructor.  Once  these  functions  are  de¬ 
termined,  examining  them  in  relation  to  human  perceptual,  con¬ 
ceptual  and  motor  capabilities  and  characteristics  will  help 
determine  the  manning  loads  and  instructor  placement  require¬ 
ments  for  the  various  training  tasks . 

11.1.1.1  Simulated  Tank  Systems.  The  instructor  requires  the 
capability  to  set  up,  monitor  and  modify  the  following  simula¬ 
ted  tank  systems: 
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a.  Tank  and  turret  position,  heading,  and  ground  speed 
(including  acting  as  driver) . 

b.  Fuel  and  oil  systems  pressures  and  levels. 

c.  Engine  temperature  and  rpm. 

d.  Transmission  selection. 

e.  Brake  system. 

f.  Main  gun  orientation,  breech  movement,  safety  control. 

g.  .50  caliber  loading  and  performance. 

h.  7.62  coaxial  machine  gun  loading 

i.  Sighting, ranging, and  firing  system  readings  and  perform-  ' 
ance. 

j.  Radio  and  intercom  system  selection,  volume  and  static 
or  jamming. 

k.  Associated  aural  cue,  vibration. 

l.  Malfunctions  as  described  in  Section  11.1.7.2. 


11.1.1.2  Simulated  Operating  Environment.  The  instructor 
requires  the  capability  to  set  up,  monitor,  and  modify  the  follow¬ 
ing  aspects  of  the  simulated  operating  environment: 

a.  Visibility  -  both  direct  viewing  and  using  special  op¬ 
tics  and  viewing  devices. 

b.  Surface  characteristics  -  audiofrictional  and  vibratory/ 
motion  cues  associated  with  various  types  of  terrain. 
(Specifically  pavement,  soil,  gravel,  and  amplitude  and 
frequency  of  perturbations  in  these  surfaces) . 

c.  Monitor  only:  Orientation  and  location  of  significant 
programmed  contours,  foliation,  terrain  features  and 
fixed  cultural  features  in  the  operating  area  of  the 
simulated  (own)  tank. 

d.  Location,  direction,  type  of  vehicle,  speed  of  movement 
and  reaction  to  the  simulated  tank  of  up  to  5  moving 
threats  and  15  stationary  threats.  The  instructor  must 
know  when  threats  move  into  line  of  sight  positions, 
signifying  the  earliest  point  at  which  an  engagement 
might  begin. 
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11.1.1.3  Advanced  Training  Features.  The  instructional  sys¬ 
tem  must  provide  sufficient  control  and  display  capabilities 
to  allow  the  appropriate  use  of  the  following  advanced  train¬ 
ing  features : 

a.  Malfunctions: 

1.  Review  malfunctions  by  system. 

2.  Insert  malfunctions. 

3.  Delete  malfunctions. 

4.  Delete  all  active  malfunctions. 

5.  Monitor  all  active  malfunctions  by  number  and 
description. 

6.  Inhibit  preprogrammed  malfunctions. 

b .  Weapons : 

1.  Select  weapon  malfunctions. 

2.  Display  and  control  threat  and  friendly  firing  and 
reaction  to  the  own  tank  (manually  or  automatically) . 

3.  Select  target  to  be  engaged  or  target  sequence. 

4.  View  map,  visual,  and  alphanumeric/graphic  displays 
of  gunnery  performance. 

c.  Hardcopy:  Store  "snapshots"  of  the  alphanumeric/map 
displays . 

d.  Map  Control: 

1.  Display  appropriately  scaled  tactical  contour  maps 
with  own  tank  and  threat  track. 

2.  Erase  ground  track. 

e.  Reverse/Advance  Multiple  Page  CRT  Displays  (e.g.,  mal¬ 
functions)  . 

f.  Data  Clear  -  Clear  all  data  accumulated  during  a  previ¬ 
ous  training  session  and  reinitialize  to  a  clean  condi¬ 
tion. 

g.  Freeze  the  entire  training  problem  and  monitor  when  a 
freeze  condition  exists. 

h.  Select  demonstrations,  preprogrammed  test  exercises,  or 
record/playback  sections.  Thirty  minutes  of  record/ 
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playback  is  specified.  The  best  method  would  be  to 
divide  the  total  capacity  into  engagement  replays  for 
instructor  selection,  for  corrective  instruction,  or 
positive  reinforcement,  or  for  instructor  debriefing. 
Segments  of  one  minute  should  be  sufficient  for  properly 
recording  an  engagement. 

i.  Adaptive  training.  In  order  to  provide  more  efficient 
crew  training,  the  instructor  will  require  the  capability 
to  adaptively  alter  the  following  training  features. 

1.  Simulated  tank  system  characteristics  as  discussed  in 
Section  11.1.1.1. 

2.  Sophistication  of  threat  tactics. 

3.  Reaction  time  and  accuracy  of  threat  fire. 

4.  Kill  radius  of  own  tank  rounds. 

5.  Apparent  velocity,  smoke  trackability  and  other 
factors  affecting  own  round  sensing. 

6.  Crew  feedback  on  threat  positions,  movement,  strength 
and  tactics.  (For  example:  Perhaps  the  tank  commander 
might  be  shown  a  real-time  tactical  terrain  map  during 
early  tactics  familiarization  training) . 

7.  Level  of  simulated  tank  dynamics  fidelity,  or  degrees 
of  freedom  of  motion. 

8.  Field  of  view  and  resolution  degradation  as  the  crew 
becomes  more  skilled. 

11.1.1.4  Crew  Performance  Monitoring  and  Evaluation.  During 
training  operations  in  the  FCIS  device,  the  instructor (s)  must 
be  capable  of  the  following  functions: 

a.  Monitor,  analyze  and  evaluate  individual  crew  member's 
actions  and  reactions  (including  normal  and  emergency 
procedures  and  intracrew  reactions  to  a  variety  of  terrain 
and  threat  stimuli) 

b.  Monitor,  analyze  and  evaluate  coordinated  crew  actions 
and  reactions  (including  normal  and  emergency  procedures 
and  a  variety  of  friendly  force,  terrain  and  threat  force 
stimuli) 

c.  Adaptively  vary  the  tactical  environment  to  tax  the  crew 
without  overwhelming  them  -  to  locate  and  eliminate  in¬ 
dividual  crew  weaknesses.  This  will  require: 

1.  Capability  to  observe  and  identify  any  weak  point  in 
individual  or  crew  actions. 
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2.  Knowledge  of  type  and  location  (including  when  detec¬ 
tion  and  kill  positions  are  reached)  of  all  friendly 
and  threat  forces. 

3.  Capability  to  coordinate  friendly  armor  and  artillery 
fire. 

4.  Capability  to  use  visual  scene  and  dynamic  tactical 
maps  to  determine  best  routes,  best  firing  positions, 
best  offensive  and  defensive  actions  and  reactions 
from  which  to  evaluate  and  modify  crew  headwork  and 
actions . 

d.  Make  use  of  advanced  training  capabilities,  especially 
playback  and  hardcopy,  in  monitoring  and  evaluation  tasks 

e.  View  gunner's  sight  picture. 

f.  Initiate  engagement  timing  sequence  when  line-of -sight 
with  target  established,  and  record  the  time  of  the  fol¬ 
lowing  events : 

1.  Line  of  sight  reached 

2.  Threat  sighted  by  crew  and  identified 

3.  Commander's  lay  complete 

4.  Target  acquired 

5.  Proper  round  loaded  and  ready 

6.  Driver  actions  complete  or  proper 

7.  First  round  away 

8 .  Round  sensed 

9.  Corrections  complete 

10.  Subsequent  round  away 

11.1.1.5  Additional  Control-Display  Requirements.  The  fol¬ 
lowing  controls  must  be  provided  at  each  instructor  station 
and  also  at  the  driver  and  fighting  stations: 

a.  EMERGENCY  STOP/POWER  CUTOFF  to  the  entire  complex 

b.  MOTION  ON/OFF  control/indication 

c.  FREEZE  control/ indication 

d.  Emergency  inter communicat ions  with  each  other  and  the 
computer  complex. 
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11.1.1.6  Locus  and  Manning.  These  requirements  are  best 
determined  experimentally,  but  in  the  absence  of  experimental 
evidence,  it  is  recommended  that  worst-case  conditions  be 
allowed  for.  This  would  be  during  high-density  tactical  en¬ 
gagements  when  the  automatic  performance  monitoring  systems 
would  be  fully  employed,  and  both  the  turret  crew  and  the  driver 
actions,  coordination  and  visual  scene  reactions,  would  need  to 
be  carefully  monitored  to  identify  those  errors  in  judgment 
and  inefficiencies  that  cost  vital  split  seconds  during  battle 
engagements.  Visual  contact  with  the  crew  is  the  most  effic¬ 
ient  and  accurate  method  of  detecting  those  weaknesses. 

An  additional  instructor  is  required  at  a  remote  location  to 
monitor  and  control  the  complex,  battle  environment,  especially 
the  movement  and  fire  of  a  highly  mobile  threat  force  of  battle 
tanks.  Thus,  during  training,  as  many  as  three  instructor/ 
observors  might  be  required,  a  main  tactical  controller  and  an 
instructor/ observer  at  each  crew  training  station.  During  cer¬ 
tain  experiments , a  fourth  individual  will  be  required  to  ob¬ 
serve  the  instructional  techniques  or  provide  additional  real¬ 
time  problem  modification  inputs. 

11.1.2  Experimental  Requirements .  Additional  display  and 
control  features  to  those  defined  for  the  instructor  are  nec¬ 
essary  to  perform  the  desired  experimental  functions  of  the 
FCIS-LM  device.  This  is  primarily  due  to  the  experimenter's 
need  for  a  more  powerful  analysis  tool,  and  also  to  the  fact 
that  in  some  instances,  the  experimenter  role  will  be  met  by 
the  instructor.  The  need  to  operate  the  FCIS-LM  device 
solely  with  an  instructor/ experimenter  is  defined  by  the  set 
of  experiments  in  which  the  "instructor"  plays  a  passive  role 
and  where  experimental  results  are  identified  and  collected  by 
the  computational  system. 

In  the  following  typical  experiments,  it  is  assumed  that  the 
data  collected  during  the  experiment  will  be  processed  and 
analyzed  at  the  conclusion  of  the  experiment. 

a.  Determining  the  importance  and  impact  in  the  use  of 
motion  on  task  performance. 

b.  Reassessment  of  crew  response  time  as  related  to  visual 
cue  enhancement. 

c.  Evaluating  capacity  of  FCIS-LM  device  for  conducting 
training  in  specific  tasks. 

In  this  group  of  experiments,  the  issue  is  not  whether  the 
crew  achieves  the  desired  level  of  proficiency,  but  whether 
variations  in  simulation  fidelity  can  be  relevant  to  training 
at  all.  Therefore,  data  required  to  make  these  evaluations 
must  be  quantified  and  collected  as  part  of  the  simulation 
system. 
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The  specific  needs  of  the  experimenter,  after  the  problem  has 
been  initiated  and  the  majority  of  his  instructor's  role  tasks 
are  completed,  are  analytical  in  nature.  These  needs  can  be 
categorized  as  (a)  instantaneous  data  either  in  raw  or  pro¬ 
cessed  form  and  (b)  trend  data.  Instantaneous  data  can  simply 
be  current  values  of  variables  in  the  simulated  problem; 
measures  such  as  elapsed  time  since  target  acquisition,  and 
the  like.  They  may  also  take  the  form  of  standard  statistical 
measures  such  as  RMS,  maximum  deviation,  power  spectral  density, 
etc.  The  other  class  of  data  is  time  history  or  trend  data. 
Trending  data  can  relate  to  either  raw  simulation  parameters 
or  processed  data. 

For  this  type  of  information  to  be  available  to  the  experimenter, 
the  control  station  must  be  capable  of  performing  two  specific 
functions.  The  first  is  to  access  in  real-time,  any  piece  of 
information  residing  in  the  simulation  data  pool  and  display  it 
in  meaningful  format  at  the  control  station.  The  second  func¬ 
tion  required  is  the  ability  to  display  this  same  data  in  time 
history  or  X-Y  format  (where  x,  y  occur  at  the  same  instant  in 
time) .  The  equipment  at  the  control  station  should,  if  feasi¬ 
ble,  have  the  capability  to  store  past  values  of  the  data, 
rather  than  retain  it  in  computer  memory,  since  this  latter 
function  would  require  excessive  amounts  of  storage  space  and 
impose  an  unnecessary  requirement  on  computational  system 
equipment. 

An  adjunct  capability  to  the  display  of  data  pool  information 
is  the  need  to  alter  certain  simulation  variables  from  the  ex-  ' 
temal  control  console.  The  combination  of  this  capability  with 
the  display  requirement  leads  to  the  need  for  the  experimenter 
to  be  able  to  generate  either  real-time  displays  or  trend  dis¬ 
plays  on-line  rather  than  live  with  preconceived  data  display 
requirements.  This  flexibility  will  provide  the  experimenter 
with  a  powerful  tool  to  be  used  during  the  conduct  of  experi¬ 
ments.  It  will  also  allow  him  to  reformat  display  data  to  be 
monitored  without  interrupting  the  experiment, and  look  at  new 
data  in  conjunction  with  other  data  previously  defined  as 
relevant. 

Another  experimental  requirement  is  in  pre-defining  or  pre- form¬ 
ulating  the  experiment  to  be  conducted.  This  must  include  the 
capability  to  establish  the  problem,  automatically  modify  cer¬ 
tain  aspects  (such  as  insertion  of  failures) ,  change  environ¬ 
mental  conditions,  alter  experimental  conditions,  and  so  on. 

The  system  should  operate  on  action/reaction  cues,  where  com¬ 
puter  software  monitors  the  simulator  state  and  takes  pre¬ 
scribed  action  when  certain  conditions  are  met.  This  system 
must  be  activated  with  a  minimum  of  instructor  or  experimenter 
action  and  should  be  totally  automatic  once  initiated. 

In  summary,  the  experimenter  must  have  the  following  capabil¬ 
ities  : 
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a.  Perform  all  instructor  tasks. 

b.  Ability  to  access  control  and  display  any  simulator 
variable. 

c.  Display  trend  data. 

d.  Have  the  ability  to  alter  real-time  display  formats  on¬ 
line  without  interrupting  experiments. 

e.  Define  the  trend  data  to  be  displayed  at  the  experimenter 
console  on-line  during  experimentation. 

f.  Develop,  initiate,  and  alter  pre- formulated  experiments 
on-line. 

11.1.3  INSTRUCTOR  STATION 

11.1.3.1  Instructor  Driving  Provisions.  The  statement  of 
work  specifies  detailed  requirements  for  instructor  driving 
controls  when  operating  the  simulated  vehicle  in  an  override 
mode.  During  the  study,  it  was  determined  that  providing  a 
duplicate  set  of  tank  driving  controls  represented  the  least 
cost  effective  approach.  Although  duplicate  controls  would  be 
familiar  to  the  instructor,  the  burden  of  operating  the  vehicle 
just  like  the  real  world  would  distract  the  instructor  from 
his  primary  role  as  observer  and  teacher.  In  addition,  in¬ 
structor  controls  to  meet  the  SOW  requirements  of  vehicle  oper¬ 
ation  from  startup  to  shutdown,  provide  no  training  benefit. 
Therefore, a  simplified  approach  to  instructor  operation  and 
control  is  considered  adequate  and  several  approaches  have 
been  identified. 

11.1.3.1.1  Keyboard/Display  Page  Approach.  This  method 
would  utilize  the  display  system  and  function  keyboard  for 
driving  control.  The  display  page  would  contain  both  control 
and  status  parameters  as  shown  in  Figure  11-1.  When  instructor 
override  is  selected  (by  editing  the  display  page) ,  the  engine 
would  be  started  automatically.  Using  the  function  keys: 
FORWARD,  REVERSE,  LEFT  TURN  and  RIGHT  TURN,  the  instructor  can 
control  the  direction  of  the  simulated  vehicle  while  referencing 
the  visual  scene  on  his  visual  repeater.  Speed  would  be  con¬ 
trolled  by  a  potentiometer.  A  neutral-steer  turn  would  be 
executed  by  setting  the  speed  control  to  zero  and  selecting 

the  function  key  for  the  desired  turn  direction.  Deletion  of 
instructor  override  mode  would  shut  down  the  engine. 

11.1.3.1.2  Joystick/Display  Page.  This  approach  to  instruc¬ 
tor  driving  control  would  utilize  a  joystick  and  display  page. 
The  display  page  operation  would  be  identical  to  that  described 
in  the  Keyboard/Display  Page  Approach.  The  joystick  would 
provide  directional  and  speed  control  with  speed  proportional 
to  the  displacement  of  the  joystick.  Activation  of  a  joystick 
button  would  initiate  a  neutral-steer  turn.  Releasing  the 


ENGINE 

GEAR  SHIFT  POSITION  X 

BRAKES  XX  PS I 

SPEEDOMETER  XX  MPH 

GROUND  SPEED  XX  MPH 

MISCELLANEOUS  SYSTEMS 

TURRET  POSITION  TO  HULL  XXX 

GUN  ELEVATION  (REFERENCE  TO  HULL)  XX 

HYDRAULIC  GAUGE  XXXX 

GUEL  QUANTITY  XXXX 

MASTER  SWITCH  XXX 

TURRET  HYDRAULIC  POWER  SWITCH  XXX 

TURRET  SEAL  .  XXXXXX 

GAS  PARTICULATE  XXX 

DRIVING  CONTROL 

INSTRUCTOR  OVERRIDE  XXX 


Figure  11-1  TYPICAL  SYSTEM  STATUS  PAGE 

joystick  returns  it  to  neutral  center  position.  To  permit  the 
instructor  to  maintain  a  desired  track  for  a  period  of  time# 
without  requiring  him  to  continuously  hold  the  joystick,  a  HOLD 
function  switch  would  be  provided.  When  this  switch  is  activ¬ 
ated,  the  direction  and  speed  will  be  maintained  and  the  joy¬ 
stick  may  be  released. 

11.1.3.1.3  Trackball/Display  Page.  With  this  approach, a 
trackball  and  display  page  would  be  used.  Once  again  the  display 
page  would  be  the  same  as  for  the  previous  approaches.  As  with 
the  joystick,  the  trackball  would  provide  both  direction  and 
speed  control.  The  trackball  would  not  return  to  neutral  when 
released, so  it  could  be  left  in  any  position  to  maintain  a 
desired  track.  A  function  switch  would  be  provided  to  initiate 
a  neutral-steer  turn. 
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11.1.3.1.4  Steering  Bar/Display  Page.  In  this  approach  a 
steering  T-bar,  speed  control, and  display  page  would  be  combined 
to  provide  instructor  driving  control.  The  steering  bar  would 
be  a  handsize  replica  of  the  tank  steering  control  with  a  button 
on  each  end  for  neutral-steer  turn  control.  The  T-bar  would 
provide  directional  control  while  speed  control  would  be  imple¬ 
mented  with  a  potentiometer  or  function  key.  The  display  page 
would  be  identical  to  that  used  in  the  other  approaches. 

11.1.3.2  Vehicle  Position  Chart  (VPC) .  Several  systems  can 
be  formulated  to  instantaneously  display  the  position  of  the 
own  tank  and  tactical  targets  with  respect  to  fixed  cultural  and 
geographic  scenario  elements.  The  basic  requirement  is  to  pro¬ 
vide  relative  position  with  reference  to  own  tank  position  on 
topographical  map  plates.  One  method  would  be  to  use  an  X-Y 
recorder  (pen  and  ink  recorder) .  Fixed  geographical  and  cultur¬ 
al  information  can  be  portrayed  in  this  manner, using  either 
real-world  paper  maps  or  slides  of  these  maps.  Another  method 
would  employ  a  CRT  type  terminal.  This  alternative  has  two 
possible  subsolutions .  The  first:  using  a  stroke  writing  or 
random  scan  terminal  where  all  information  portrayed  is  gener¬ 
ated  by  the  simulator  computer  and  drawn  by  the  CRT  display 
system;  the  second:  using  a  raster  type  (home  TV)  display 
system.  Both  of  these  systems  would  permit  the  superimposing 
of  videotape  images  of  fixed  maps  and  the  positioning  of  moving 
targets  and  owntank  via  computer  generated  graphics  symbology. 
Still  another  way  to  solve  this  problem  is  the  use  of  a  plasma 
or  flat  panel  display  terminal.  This  concept  is  very  similar  to 
the  raster  display  system  concept.  The  difference  being  that  it 
can  be  used  in  conjunction  with  a  slide  or  microfiche  projector 
to  project  slides  of  a  fixed  map  area  on  the  back  of  the  view¬ 
ing  screen  with  computer  generated  symbology  superimposed  on 
the  map  area.  The  utilization  of  an  X-Y  recorder  has  several 
advantages  and  disadvantages .  The  advantages  are: 

a.  Several  types  available  and  easily  adapted  for  the 
purpose . 

b.  Completed  charts  from  the  recorder  could  be  used  directly 
for  debriefing  purposes . 

The  major  disadvantages,  which  far  outweight  the  advantages,  are 

a.  It  is  a  mechanical  device,  with  slow  response  time  and 
would  be  unduly  stressed  to  cope  with  multiple  moving 
target  situations. 

b.  No  capacity  to  present  current  moving  target  symbology 
without  cluttering  the  map  face. 

c.  Need  to  change  chart  for  each  exercise. 

The  slide  system  would  be  somewhat  more  flexible  in  that  the 
user  is  only  required  to  old  maps  and  track  histories  with 
a  cloth  and  cleaning  fluid.  While  those  systems  have  been 
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used  extensively  in  the  past  for  training  and  experimental 
devices,  they  have  been  superseded  by  all-electronic  systems 
that  are  more  reliable,  more  flexible,  require  less  floor 
space  and  are  of  lower  cost. 

The  next  approach  to  be  explored  is  a  random-scan  graphic  dis¬ 
play  system.  This  type  of  display  system  is  in  overwhelming 
favor  over  all  of  the  types  used  for  vehicle  position  charts. 
These  systems  usually  are  driven  by  a  display  processor  which 
takes  computer  generated  information  and  draws  the  required 
image. 

Display  generators  can  drive  up  to  four  separate  display  tubes. 
Stroke  writing  systems  work  basically  in  the  same  way  as  a 
X-Y  recorder.  The  computer  directs  the  position  of  the  elec¬ 
tron  beam  to  any  random  location  on  the  CRT  surface  and  shapes 
any  symbol,  curve,  or  line  that  has  to  be  drawn.  This  system 
has  a  high  initial  cost  for  the  basic  hardware  which  includes 
an  interface  unit  for  use  with  the  digital  computer,  display 
generation  equipment,  and  of  course  at  least  one  display  unit. 
Expansion  to  two  or  three  additional  display  units  requires 
nominal  additional  costs.  The  advantage  of  this  system  is 
that  all  information  generated  by  computer  programs  can  be 
changed  quickly  and  easily.  Symbology  representing  cultural 
targets,  topographical  features,  own  tank  current  position, 
pertinent  data  legends  for  annotating  parameters  such  as  speed 
and  direction  of  tanks,  targets,  etc.,  are  all  generated  by 
computer  programs.  Changing  to  a  new  tactical  situation  or 
selecting  a  new  exercise,  requires  only  a  re- initiation  of  a 
previously  stored  computer  program.  The  cost  of  graphic  dis¬ 
play  systems  is  not  as  high  as  one  might  expect.  Generally, 
basic  systems  that  can  provide  the  capability  to  depict  FCIS 
own  tank  position,  several  targets,  and  fixed  geographical  and 
cultural  references  could  be  procured  for  less  than  $20,000 
(without  refresh  memory) .  Although  software  must  be  generated 
(the  driving  mechanism),  it  is  reusable  and  therefore  can  be 
amortized  over  many  systems.  A  further  significant  advantage 
to  this  type  of  a  vehicle  position  chart  lies  in  the  fact  that 
it  can  be  used  for  other  purposes  such  as  experimenter  display 
and  control  functions  for  monitoring  the  results  of  experiments. 
This  will  be  explored  further  in  subsequent  sections. 

Another  type  of  display  system  commonly  used  as  a  vehicle  posi¬ 
tion  chart  is  a  raster  type  display  system  that  employs  commer¬ 
cial  TV  technology.  The  basic  components  are  again,  an  inter¬ 
face  unit  for  use  with  the  simulation  computer,  a  display  gen¬ 
erator,  internal  refresh  memory,  plus  display  equipment.  These 
systems  operate  in  a  similar  manner  to  the  stroke  writing  sys¬ 
tems  mentioned  previously,  but  do  have  some  technical  differ¬ 
ences.  The  stroke  writing  systems  typically  can  print  an  image 
of  approximately  1,000  by  1,000  (horizontal  and  vertical) 
addressable  elements  in  the  display,  whereas  the  raster  scan 
type  system  can  only  address  approximately  500  elements  per 
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horizontal  line  and,  because  of  the  need  for  synchronization  time, 
only  480  lines  per  vertical  frame.  This  apparent  resolution 
limitation  can  be  a  significant  factor  in  high  data  density 
displays . 

A  new  and  interesting  multiplexed  display  technology  that  is 
now  available  and  could  be  employed  for  the  VPC  is  the  plasma 
type  display.  This  display  is  constructed  of  two  laminated 
glass  plates  with  each  inside  surface  etched  with  conductive 
material.  On  one  plate  lines  are  etched  in  a  horizontal  direc¬ 
tion;  on  the  other  in  a  vertical  direction.  The  lines  inter¬ 
sect  at  approximately  256,000  points  on  the  surface  of  the 
screen  in  a  pattern  of  512  by  512.  The  space  in  between  the  two 
glass  plates  is  filled  with  neon  gas.  The  plates  are  electri¬ 
cally  excited  so  that  the  neon  gas  at  the  intersections  becomes 
ionized  in  a  sequential  manner,  and  may  be  modulated  to  produce 
displays  that  use  all  of  the  512  accurately  registered  elements 
in  both  horizontal  and  vertical  planes.  A  display  generator 
operating  in  much  the  same  way  as  the  raster  system  display 
generator  provides  the  image  modulation  information.  The 
images  can  be  either  lines,  circles,  symbols  or  characters. 

This  technology  is  available  in  another  configuration  utilizing 
a  slide  projector  to  project  a  map;  e.g. ,  a  real-world  tactical 
map  on  the  back  surface  of  the  viewing  glass  while  the  computer 
generates  the  symbology  for  moving  targets  and  FCIS,  as  well  as 
track  and  other  relevant  information.  The  result  of  this  is  a 
system  very  similar  to  a  raster  display  system  but  substantially 
lower  in  cost.  Plasma  displays  are  not  as  fast  as  raster  dis¬ 
plays  in  that  each  intersection  has  to  be  energized  or  de¬ 
energized  separately,  since  only  one  X-Y  address  can  be  ener¬ 
gized  at  any  one  time. 

At  this  time,  it  would  not  be  advisable  to  attempt  to  do  a  top 
level  trade-off  analysis  in  order  to  accept  or  reject  any  of 
these  approaches.  The  reason  for  this  is  that  several  of  the 
devices  mentioned  above  have  a  flexibility  which  will  allow  them 
to  be  used  not  only  as  a  vehicle  position  chart  but  as  a  display 
and  control  device  for  experimenters  and/or  instructors  in  the 
FCIS  system.  As  a  result,  the  trade-off  analysis  will  be  done 
after  further  discussion. 

11.1.3.3  Instructor/Experimenter  Display /Control  Tradeoff 
Analysis.  Any  synthesized  operational  system,  such  as  the  FCIS- 
LM  device  must  provide  capabilities  for  instructors  to  conduct 
and  observe  training,  for  experimenters  to  develop  experimental 
situations  and  monitor  those  situations,  as  well  as  analyze  the 
results.  Control  stations  have  differing  requirements  and  it  is 
necessary  to  consider  those  requirements  in  terms  of  the  various 
elements.  First,  the  operator  (either  the  instructor  or  experi¬ 
menter)  must  be  able  to  set  up  a  problem  prior  to  execution, 
monitor  the  state  of  the  problem  in  real  time,  retrieve  signifi¬ 
cant  data  concerning  the  problem  in  various  formats,  modify  the 
problem  if  required,  and  receive  and  store  results  about  the 
entire  problem.  In  a  simulator  such  as  the  FCIS,  where  all  of 
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the  functional  aspects  of  the  training  exercise  are  computed  in 
realtime  via  a  digital ' computer  and  reside  instantaneously  in 
core  memory;  i.e.,  a  data  pool,  the  instructor/ experimenter 
display  and  control  problem  is  reduced  to  the  simple  requirement 
of  accessing  information  within  the  data  pool  and  either  display 
ing  it,  modifying  it  as  required,  or  transforming  it.  Any  analy 
sis  to  develop  display  control  requirements  necessary  for  an  ex¬ 
perimenter  or  operator  of  this  nature  necessitates  some  investi¬ 
gation  into  the  specific  problem  areas  in  order  to  develop  a  set 
of  requirements.  One  of  the  early  requirements  identified  was 
that  of  a  vehicle  position  chart. 

Next,  it  is  necessary  to  consider  all  of  the  parameters  and  func 
tions  where  the  instructor/experimenter  must  have  direct  control 
For  example;  the  operator  should  be  able  to  position  the  simu¬ 
lated  own  tank  to  any  point  in  any  gaming  area.  Targets  in  the 
environment  must  be  initialized  to  their  starting  positions, 
the  outside  environmental  conditions  must  be  established  and  be 
controllable;  and  in  the  case  where  the  instructor  is  acting  as 
the  driver,  he  must  have  vehicle  dynamics  information  available 
as  well  as  a  means  for  controlling  and  changing  those  dynamics. 

A  further  consideration  involved  in  developing  the  layout  of 
the  control  station  is  in  how  much  information  must  be  made 
available  to  the  instructor,  and  what  kind  of,  and  how  many 
displays  are  required.  The  FCIS-LM  will  be  basically  operated 
in  two  modes;  a  training  mode  and  an  experimental  mode.  The 
training  mode  should  be  the  simplest  mode  with  the  instructor 
operating  in  this  mode  having  a  vehicle  position  chart  as  well 
as  vehicle  control  display  capability.  This  situation  can  be 
handled  with  one  display  if  that  display  can  provide  both  the 
VPC  requirements  as  well  as  the  vehicle  control  display  require¬ 
ments.  There  is,  of  course,  the  possibility  that  the  instructor 
would  lose  continuity  with  the  problem  by  changing  displays  in 
order  to  multiplex  the  different  types  of  information  on  one 
display  tube.  Thus,  although  it  is  possible  to  use  one  display, 
it  is  desirable  to  use  two. 

A  further  consideration  to  be  taken  into  account  in  this 
decision  concerns  the  cost  of  the  second  display.  Moreover, 
in  the  experimental  mode,  the  control/display  function  takes 
on  greater  magnitude  because  not  only  will  we  have  an  instructor 
operating  the  simulator  from  the  training  aspect,  but  we  will 
also  need  to  have  additional  facilities  for  the  'experimenter' 
to  perform  his  experimental  functions.  So  at  the  very 
minimum,  we  need  control/display  capability  for  the  instructor 
and  also  for  the  experimenter.  As  a  result,  it  ife,  necessary 
to  have  two  separate  displays  available  at  the  FCIS  instructor/ 
experimenter  station.  The  results  of  this  brief  Analysis  are 
summarized  in  Table  ll-l. 
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The  following  design  concepts  can  be  used  to  implement  this 
approach.  In  all  cases,  the  use  of  the  vehicle  position  chart 
will  be  incorporated  where  applicable  in  the  display  control 
requirement.  The  first  concept  would  be  to  provide  individual 
controls  for  specific  experimenter/instructor/control  require¬ 
ments.  This  would  require,  for  example,  an  X-Y  recorder  or 
slide  projector  for  vehicle  position  chart.  Readouts  and/or 
meters  related  to  the  driving  controls  would  be  necessary  as 
well  as  individual  readouts  of  other  important  environmental 
and  tactical  factors.  In  all  cases,  a  visual  repeater  is  re¬ 
quired.  Since  the  instructor  requires  display  data  entry 
capabilities,  individual  switches  and/or  potentiometers  will 
be  necessary. 


TABLE  11-1  DISPLAY/CONTROL  REQUIREMENTS 


MODE 

TRAINING 

EXPERIMENTAL 

PARAMETER 

INSTR 

EXPERI¬ 

MENTER 

INS 

EXP 

VPC 

X 

NR 

X 

MONITOR  TRAINING  PROBLEM 

X 

NR 

.  X 

X 

ENTER  DATA 

X 

NR 

X 

X 

PERFORM  DATA  ANALYSIS 

NR 

X 
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Extending  the  use  of  the  display  technology  introduced  in 
the  previous  section,  another  solution  to  the  problem  is  to 
use  two  graphic  displays  and  one  visual  repeater.  In  this 
situation,  the  graphic  displays  would  provide  a  vehicle 
position  chart,  alphanumeric  readouts  and  control,  and  the 
driver  controls.  The  vehicle  position  chart,  would  be  im¬ 
plemented  as  described  earlier.  In  addition,  several 
different  types  of  alphanumeric  display  control  pages  would 
be  generated.  These  pages  would  be  selectable  either  from  a 
matrix  of  oage  select  switches  or  could  be  selected  from  a 
tabulated  index  on  a  special  CRT  page.  Pages  would  be  grouped 
by  type  and  category  such  as,  malfunctions,  target  types, 

FCIS  (own  tank)  data,  weapon  data  readouts,  environmental 
conditions,  scoring  criteria,  etc.  One  of  the  special  func¬ 
tion  pages  would  be  the  driver  control  page,  where,  if 
operating  in  the  COFT  mode,  the  instructor  would  have  a  page 
available  with  key  entries  to  drive  the  simulator.  Hardware 
for  systems  of  this  type  are  manufactured  by  companies  such 
as  Sanders,  Aydin  Controls,  Vector-General,  Inc.,  Imlac,  In¬ 
formation  Display,  Inc.,  etc.  A  display  system  interfacing 
through  a  high-speed  parallel  interface  would  be  necessary 
with  display  controller,  internal  refresh  memory,  and  two 
display  tubes.  A  system  such  as  this  would  cost  approximately 
$40,000  (initial  procurement  cost).  Display  tubes  would  be 
19-inch  diagonals  with  a  usable  display  area  of  12-inches  x 
16-inches.  Displays  would  be  tailored  to  instructor/experi- 
menter  requirements,  with  each  page  divided  into  sub-pages: 
a  12-inch  x  12-inch  area  to  display  map  information  and  alpha¬ 
numeric  data,  and  a  supplementary  area  of  4-inches  x  12-inches 
to  be  used  for  keyboard  entry  readout,  and  other  scratch  pad  type 
data  the  instructors  and/or  experimenters  may  require. 

Raster  display  systems  will  satisfy  the  alphanumeric  display 
control  functions  discussed  earlier,  and  at  the  same  time, 
they  could  be  used  as  vehicle  position  charts  as  well.  To 
accomplish  this,  several  techniques  are  available. 

The  most  common  method  is  to  combine  computer  generated 
symbology  with  video  tape  signals  prepared  by  scanning 
photo  transparencies  of  selected  maps. 

Alphanumeric  pages  would  operate  in  the  same  way  as  they  do 
for  the  graphic  system  with  the  exception  of  sizing  and 
format.  A  typical  raster  display  system  with  a  19-inch 
diagonal  tube  would  have  a  usable  display  area  of  about 
12-inches  x  15-inches.  Systems  of  this  type  are  manufactured 
by  Aydin  Controls,  Ramtek,  Inc.  and  Genisco  Computer  Products. 

The  systems  manufactured  by  Aydin  have  the  capability  to 
drive  up  to  four  display  channels.  They  have  the  further 
capability  to  display  images  in  color. 
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The  plasma  display  mentioned  earlier  can  be  used  as  a  vehicle 
position  chart,  as  well  as  a  display  control  device  for  the 
experimenter/operator.  Products  are  available  from  several 
vendors  which  will  allow  the  incorporation  of  either  a 
microfiche  or  35mm  slide  system  to  project  background  maps 
on  the  glass  display  surface  and  then  superimpose  the 
computer  generated  symbols  for  own  tank,  targets  and  related 
ground  tracks.  Display  control  capability  would  be  handled 
in  exactly  the  same  manner  as  the  two  display  systems 
previously  mentioned.  At  the  present  time  this  system  is 
off-the-shelf  and  can  be  readily  purchased,  although  future 
procurements  may  be  questionable  since  the  u.  S.  company 
(Owens  Illinois  Company)  having  the  technology  to  produce 
the  glass  plate  element  s  has  decided  to  terminate  production. 
Whilst  other  sources  are  available  in  Japan,  this  aspect 
definitely  discredits  this  approach  for  the  FCIS-LM  at  this 
time.  On  the  other  hand,  CRT  tube  production  (both  black 
and  white,  and  color)  is  a  well  established  technology 
employed  in  mass  production  and  available  from  numerous  U.S. 
sources . 


A  top  level  tradeoff  eliminated  the  graphic  display  systems 
from  further  consideration  based  on  its  higher  procurement 
cost,  complexity  and  life  cycle  costs.  Therefore,  the  se¬ 
lection  of  an  approach  to  display  and  control  will  be  based 
on  a  tradeoff  between  raster  and  plasma  displays. 

11.1.4  Instructional  Features. 


11.1.4.1  Problem  Formulation  and  Control.  The  FCIS  problem 
situation  requires  the  instructor,  operator  and/or  experi¬ 
menter  to  establish  the  problem  situation,  and  control  that 
problem  in  real  time.  The  elements  of  the  problem  that  are 
controllable  include  the  FCIS  own  tank  and  its  related 
systems,  the  number  of  enemy  targets,  and  a  number  of 
friendly  forces.  To  understand  the  problem  of  control, 
consider  the  situation  related  to  three  enemy  targets.  If 
these  are  tanks,  each  of  them  must  have  speed  and  direction 
and  behave  in  a  proper  manner.  The  instructor,  if  he  is  to 
control  these,  and  if  any  degree  of  tactical  realism  is  to 
be  preserved,  must  have  access  to  a  pre- formulated  battle 
plan  for  these  vehicles  in  order  to  control  the  situation. 

It  will  not  be  possible  for  the  instructor  to  control  this 
situation  effectively  at  the  same  time  that  he  is  required 
to  instruct,  observe,  monitor  and  evaluate  the  FCIS  own 
tank  crew  members.  This  identifies  the  need  for  an  automated 
control  system  for  problem  situations.  The  digital  computers, 
through  program  control,  can  independently  control  as  many 
elements  of  the  problem  as  computer  capacity  allows. 

Problem  formulation  consists  of  the  following  tasks: 

a)  Initial  problem  setup. 

b)  Control  of  system  malfunctions. 
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c)  Control  of  the  tactical  scenario  with  up  to  15 
individual  elements . 

d)  Control  of  environmental  conditions. 

e)  If  necessary,  control  of  the  FCIS  own  tank  as  a 
simulated  driver. 

f)  Control  of  individual  parameters  to  alter  problem 
difficulty. 

g)  Determination  of  targets  to  be  engaged  or  target 
engagement  sequence. 

h)  Monitor  all  weapon  systems,  vehicle  control  systems, 
and  sighting  systems  control  status. 

i)  Monitor  individual  crew  members'  actions  and 
reactions  (including  normal/emergency  procedures) 
and  a  variety  of  crew  interactive  functions  in 
response  to  a  variety  of  terrain  and  threat  stimuli. 

When  the  trainer  is  used  in  a  experimental  mode,  the 
experimenter  must  be  able  to  perform  many  of  the  duties  of 
•the  instructor,  in  addition  to  having  to  access  the  infor¬ 
mation  required  to  perform  an  analysis  on-line;  e.g., 
determining  the  reaction  time  errors  to  certain  stimulus. 

All  of  these  requirements  can  be  segregated  into  two  major 
categories : 

1)  Those  tasks  which  are  quantifiable  in  nature  and 
consume  time  thus  diverting  attention  from  students. 

2)  The  instructional  tasks  or  experimenter  tasks  necessary 
and  relevant  to  the  problem  at  hand. 

An  automated  problem  control  system  can  accommodate  the 
first  category  and  relieve  the  instructor/experimenter  from 
these  time-consuming  tasks  allowing  him  to  devote  more  time 
to  the  second  set  of  tasks.  There  are  basically  two  ways 
to  implement  this  type  of  a  system.  The  first  is  to  prepare, 
in  detail,  a  "canned"  set  of  problems  where  each  specific  ? 
element  in  the  system  performs  exactly  as  defined  with  no 
deviations.  These  would  then  be  a  series  of  problems  stored 
on  a  disk  file  and  selectable  one  at  a  time  for  execution. 

The  second  method  is  to  utilize  the  computational  capacity 
of  the  trainer  computer  system  to  develop  a  series  of 
"computer  programs ," that  would  control  various  aspects  of 
the  tactical  problems.  This  approach  would  take  advantage  of 
higher  order  languages  and  eliminate  the  inflexibility  of 
a  canned  mission. 
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A  programmed  mission  can  be  designed  to  adaptively  resoond  to 
situations  in  real  time.  For  an  example,  consider  the  in¬ 
sertion  of  a  malfunction.  In  the  first  approach  after  the 
training  exercise  has  progressed  to  a  specific  point  in  the 
mission  a  weapon  system  malfunction  would  be  inserted. 

Assume  it  occurs  a  finite  time  after  initial  line-of-sight 
acquisition  of  a  threat.  This  would  be  a  good  way  to 
evaluate  crew  response  to  the  malfunction  if  the  tank 
commander  and  his  crew  followed  up  the  situation;  e.g., 
acquire  the  target  and  proceed  to  fire  the  weapon.  The 
malfunction  would  be  totally  out  of  context  and  invaluable 
for  performance  evaluation  of  the  desired  response  if  the 
crew  took  alternate  action  such  as  seeking  cover,  or  evading 
the  threat.  The  method  also  has  the  capabilitv  to  allow 
more  variables  to  be  introduced  into  the  problem;  e.g.,  this 
malfunction  would  not  be  inserted  until  the  crew  took  appropriate 
action  related  to  this  particular  problem  element  such  as 
aligning  the  main  gun  and  loading  with  appropriate  rounds. 

The  basic  difference  between  the  two  methods  is  not  in  their 
ultimate  capability  to  handle  a  specific  problem,  but  their 
overall  flexibility  as  both  these  systems  rely  on  computer 
program  capability  to  implement  control  requirements. 

However,  the  method  favored  is  that  which  is  generated  in  the 
higher  order  language  in  a  free  format.  This  system  introduces 
a  flexibility  not  found  in  the  "canned"  approach.  Each 
element  of  the  problem  can  be  categorized  as  a  subroutine 
within  Fortran  in  order  to  add  flexibility  to  this  system. 

A  further  example  of  the  flexibility  that  could  be  incorpor¬ 
ated;  consider  a  target  acquisition  exercise  within  the 
favored  formulation  system.  The  target  could  be  programmed 
to  change  speed  or  direction  based  on  reactions  of  the  FCIS 
own  tank  crew.  Whereas  in  the  "canned"  method,  once  the 
target  is  initialized,  the  outcome  would  also  tend  to  be 
"canned",  and  the  tactical  realism  of  the  exercise  would  not 
be  realized.  Both  methods,  of  course,  have  significant 
advantages  over  manual  control.  For  instance,  if  there 
were  three  moving  targets  in  the  scene,  with  the  instructor 
having  to  control  all  of  the  parameters  related  to  those 
targets  with  individual  controls ,  it  is  obvious  that  virtually 
no  time  will  be  available  for  crew  observation  and  very  little 
tactical  realism  will  be  achieved.  Thus,  the  advantages  of 
automated  problem  control  becomes  readily  apparent. 

The  recommended  design  approach  for  this  system  would  be  one 
that  operates  with  real-time  overlays.  Each  problem  would 
be  defined  off-line  in  a  higher  order  language  (HOL) ,  such  as 
Fortran.  Individual  problem  elements  such  as  initial 
conditions  and  environmental  factors,  target  parameters, 
malfunctions,  etc.,  would  be  developed  separately  and 
stored  on  separate  disk  files.  An  entire  problem  would  be 
constructed  by  selecting  individual  elements  from  these 
files.  The  system  also  would  have  the  capability  to  perform 
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real-time  data  analysis  as  related  to  experimenter  tasks. 
Systems  of  this  nature  have  been  incorporated  in  previous 
research  tool  type  simulators  (ASUPT  and  VTFS).  The 
effort  to  develop  viable  problems  is  performed  at  a  desk 
and  off-line  at  the  10  console.  Once  the  task  is  completed, 
the  user  (either  the  instructor  or  experimenter)  would 
simply  select  the  appropriate  function  through  the  display 
control  system. 

11.1.4.2  Record/Playback.  The  training  value  of  confront¬ 
ing  a  crew  or  crew  member  with  a  replay  of  a  portion  of  a 
training  exercise  is  well  accepted  and  a  record/playback 
capability  should  be  incorporated  in  the  FCIS-LM.  The 
following  summaries  define  approaches  to  record/playback 
previously  implemented  on  various  aircraft  simulators. 

a)  Record  Inputs  -  In  this  approach  a  history  of  the 
crew's  inputs  to  the  simulator  are  recorded  in 
digital  form.  The  playback  is  produced  by  function¬ 
ally  disabling  the  control  inputs  from  the  cockpit 
and  replacing  them  in  the  computer  with  the  recorded 
inputs.  The  normal  computational  functions  of  the 
computer  are  exercised  as  if  the  crew  were  operating 
the  simulator.  The  system  requires  programs  to  handle 
the  I/O  and  disable  the  controls  during  playback. 

This  necessitates  running  the  playback  program  during 
spare  computer  time.  Some  form  of  bulk  storage  device 
is  required.  Additional  hardware  is  required  to 
control  the  system. 

b)  Record  Inputs  and  Selected  Internal  Variables  -  This 
approach  is  the  same  as  a)  except  that  certain 
equation  outputs  are  recorded,  and  during  playback, 
the  computed  values  of  the  equations  are  replaced  by 
the  recorded  values  at  a  rate  that  prevents  errors 
from  propagating.  This  technique  permits  a  reduction 
in  the  input  rate  to  the  computer  from  the  recording 
medium . 

c)  Record  Inputs  and  All  Outputs  -  In  this  approach  all 
outputs  and  inputs  to  the  simulator  are  recorded. 
During  playback,  values  of  the  recorded  inputs  are 
used  to  drive  the  flight  controls,  while  outputs  are 
used  to  drive  displays.  The  computational  function 
of  the  computer  is  bypassed.  Programs  are  required 
to  handle  the  I/O  and  perform  the  executive  function. 
Hardware  requirements  are  the  same  as  for  the  previous 
approaches . 

d)  Record  Outputs  -  A  further  approach  is  to  record  only 
the  outputs  of  the  vehicle  systems  in  response  to 
control  inputs.  During  playback,  crew  inputs  are  dis¬ 
abled  and  computation  is  stopped.  The  system  simply 
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provides  the  outputs  as  recorded.  Executive  and  I/O 
programs  are  required  along  with  hardware  similar  to 
that  for  the  previous  approaches.  The  controls  are 
not  moved  during  this  approach. 

Link ' s  experience  indicates  that  approach  b)  'Record 
Inputs  and  Selected  Internal  Variables',  yields  the  most 
satisfactory  playback  and  recommends  this  approach  for  the 
FCIS-LM. 

The  FCIS  application  of  the  SOW  requirement  for  the  most 
recent  thirty  minutes  does  not  provide  the  most  effective 
training.  Tank  engagements  are  of  short  duration.  To 
achieve” maximum  value  of  the  recorded  performance  the 
record/playback  capability  should  allow  the  instructor  to 
record  and  then  playback  selected  segments  of  simulator 
performance.  A  total  of  30  one-minute  segments  of  recording 
time  should  be  available.  The  instructor  should  have  record/ 
"playback  control  via  display  and  control  function  keys.  He 
must  be  able  to  initiate  a  recording,  select  segments  for 
playback,  freeze  and  unfreeze  a  playback,  and  erase  or 
overwrite  a  recorded  segment.  The  instructor  must  also  be 
able  to  select  normal  or  half-time  playback.  Playback  does 
not  destroy  the  recorded  data.  When  playback  of  a  segment  is 
complete,  the  system  retains  the  conditions  existing  at  the 
end  of  the  playback  segment. 

Record/playback  records  are  generated  by  on-line  real-time 
software.  For  every  one-minute  segment,  a  large  initializa¬ 
tion  record  is  stored  on  the  disk.  Each  initialization 
record  contains  sufficient  data  to  reset  the  state  of  all 
simulated  systems  to  this  point  in  time.  During  the  one- 
minute  interval,  the  record  program  collects  and  buffers  in¬ 
puts  to  the  computer  from  the  vehicle  controls  and  specific 
variables  resulting  from  simulation  computations.  Values 
are  recorded  at  a  rate  corresponding  to  the  generation  or 
utilization  of  the  data  by  the  simulation  routines.  These 
smaller  reproduction  records  are  sized  so  that  data  can  be 
efficiently  transferred  to  the  disk.  When  recording  is 
terminated,  the  file  content  record  (on  disk)  is  updated 
with  pointer  and  control  information  to  be  used  for  display 
of  segments  used  and  for  replay  control. 

Replay  is  accomplished  by  an  on-line  real-time  routine  which 
utilizes  the  initialization  data  to  return  each  simulated 
svstem  to  the  state  existing  at  the  time  the  initialization 
data  was  recorded.  Upon  completion  of  the  initialization 
process,  the  simulator  will  be  in  the  freeze  mode  (functions 
of  time  will  be  halted).  Also,  all  inputs  to  the  computer, 
corresponding  to  those  which  were  recorded,  are  discontinued 
for  the  duration  of  the  replay.  When  freeze  is  released 
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bv  the  instructor,  reproduction  data  records  are  retrieved 
from  the  disk  and  the  incut  and  internal  variable  values 
distributed  in  a  manner  that  is  essentially  the  inverse  of 
the  collection  process. 

In  flight  simulators,  the  primary  flight  controls  and  rudder 
pedals  are  driven  during  playback  to  simulate  the  control 
movements  that  occurred  during  the  recording  period. 

Secondary  controls  such  as  throttles,  flap  handle,  and 
switches,  etc.,  are  not  moved  during  the  playback,  but  the 
effects  of  their  movement  are  visible  on  cockpit  instrumen¬ 
tation.  Due  to  the  largely  analog  nature  of  the  tank 
systems,  further  study  is  required  to  determine  the  most 
effective  systems  operation  during  playback. 

Two  approaches  to  instructor  station  displays  during  record/ 
playback  have  been  utilized  in  the  past.  One  approach 
involves  recording  the  selection  of  the  display  pages  and 
recalling  them  during  playback.  The  other  does  not  record 
display  selections  so  that  during  playback  the  instructor  is 
free  to  choose  the  display  most  pertinent  to  the  situation. 

In  both  approaches,  changes  to  the  simulation  problem  entered 
via  the  display/control  system,  are  recorded  and  replayed  at 
the  appropriate  time.  In  order  to  provide  maximum  flexibility 
to  the  instructor,  the  second  approach  is  recommended  for 
FCIS-LM  instructor  station  displays. 

11.1.4.3  Performance  Monitoring.  The  performance  monitor¬ 
ing  capability  required  by  the  FCIS  must  incorporate  not 
only  individual  crew  task  assessment  and  full  crew  inter¬ 
active  assessment,  but  must  also  provide  the  experimenter 
with  the  capability  to  assess  results  of  the  various  experi¬ 
ments  that  will  be  performed  with  this  laboratory  model. 

As  a  result,  an  evaluation  of  only  the  crew  tasks  would  not 
be  sufficient  to  develop  requirements  for  a  performance 
monitoring  system.  Considerable  attention  must  be  paid  to 
the  needs  of  the  experimenter  on  this  synthetic  system. 

Thus,  any  performance  monitoring  systems  incorporated  must 
include  not  only  performance  monitoring  capabilities  for 
specific  tactical  training  situations,  but  must  also  address 
the  experimental  situation. 

Table  11-2  summarizes  several  engagements  for  the  M60A3 
operational  tank  typifying  problems  that  would  be  presented 
to  crews  in  the  FCIS.  This  serves  as  a  data  base  from  which 
to  establish  the  performance  monitoring  requirements  related 
to  instructing  and  accordingly  provides  the  basis  for 
determining  the  types  of  performance  monitoring  capabilities 
that  are  required  at  the  instructor/experimenter  control 
station.  Review  of  this  data  indicates  that  during  engage¬ 
ments,  several  control  activations  are  made,  such  as,  index¬ 
ing  ammunition  into  ballistics  computer,  selecting  firing 
switches,  loading  rounds,  etc.  This  identifies  the  need  to 
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TABLE  11-2  SCENARIO  INDEX  FOR  M60A3  TANK,  BASED  UPON  TABLE  VIII  A  AND  B 
(TWENTY  ENGAGEMENTS)  STABILIZED  MODE 


ENGAGE¬ 

MENT 

TANK  MODE 

TARGET  DESCRIPTION 

TYPE  ENGAGEMENT 

RANGE 

ILLUMI¬ 

NATION 

OTHER 

1 

MOVING  TANK 

TANK  FRONT  SHOT 

-  - 

BATTLESiaiT 

HEAT 

900 

METERS 

DAY 

2 

MOVING  TANK 

MOVING  TRUCK 

.  .  -  — 

CAL  50 

700 

METERS 

DAY 

3a 

MOVING  TANK 

MOVING  TANK 

BATTLES  I  (MT 

1200 

METERS 

DAY 

MULTIPLE 

3b 

MOVING  TANK 

MOVING  TANK 

APDS 

1600 

METERS 

DAY 

ENGAGE¬ 

MENT 

4 

MOVING  TANK 

TROOPS 

COAX 

600 

METERS 

DAY 

5 

STATIONARY 

TANK 

ANTITANK 

PRECISION 
TELESCOPE  HEP 

1600 

METERS 

DAY 

6 

MOVING  TANK 

HELICOPTER 

CAL  50 

900 

METERS 

NIGHT 

7 

STATIONARY 

TANK 

TANK  FRONT  SHOT 

BATTLESIGHT 

HEAT 

1000 

METERS 

NIGHT 

THERMAL 

siott 

8 

STATIONARY 

TANK 

TROOPS 

CAL  50 

1200 

METERS 

NIGHT 

THERMAL 

SIGHT 

9 

STATIONARY 

TANK 

TANK  FRONT  SHOT 

PRECISION 

ADPS 

1800 

METERS 

NIGHT 

THERMAL  i 
SIGHT  I 

10 

MOVING  TANK 

SUSPECTED  TARGET 

SUPPRESSIVE 

FIRES 

LOADERS  MG 

■ 

100 

METERS 

NIGHT 

11 

MOVING  TANK 

HELICOPTER  ATGM 

_ 

CAL  50 

1000 

METERS 

DAY 

EVASIVE 

MOVES 

12 

STATIONARY 

TANK 

TANK  FRONT  SHOT 

PRECISION 

ADPS 

1900 

METERS 

DAY 

SIMUL¬ 
TANEOUS 
WITH 
ENGAGE¬ 
MENT  13 

TABLE  11-2  SCENARIO  INDEX  FOR  M60A3  TANK,  BASED  UPON  TABLE  VIII  A  AND  B 
(TWENTY  ENGAGEMENTS)  STABILIZED  MODE  (CONT'D) 


ENGAGE¬ 

MENT 

TANK  MODE 

TARGET  DESCRIPTION 

TYPE  ENGAGEMENT 

RANGE 

ILLUMI¬ 

NATION 

OTHER 

13 

STATIONARY 

TANK 

TROOPS 

CAL  50 

1500 

MEIERS 

DAY 

SIMUL¬ 
TANEOUS 
WITH 
ENGAGE¬ 
MENT  12 

14 

MOVING  TANK 

TANK  FRONT  SHOT 

BATTLESIGHT 

HEAT 

800 

MEIERS 

DAY 

15 

MOVING  TANK 

SUSPECTED  TARGET 

SUPPRESSIVE 
FIRES  COAX 

500 

METERS 

DAY 

16 

MOVING  TANK 

TANK  FRONT  SHOT 

BATTLESIOrr 

HEAT 

800 

METERS 

NIGHT 

THERMAL 

SIOfT 

17 

MOVING  TANK 

MOVING  TRUCK 

COAX 

700 

metErs 

NIGHT 

THERMAL 

SIGHT 

18a 

MOVING  TANK 

TANK  FRONT  SHOT 

BATTLESIGHT 

1300 

METERS 

NIGHT 

MULTIPLE 

18b 

MOVING  TANK 

TANK  FLANK  SHOT 

ADPS 

• 

1500 

METERS 

THERMAL 

SIGHT 

ENGAGE¬ 

MENT 

19 

MOVING  TANK 

TROOPS 

COAX 

600 

METERS 

NIQfT 

THERMAL 

SIOfT 

20 

STATIONARY 

TANK 

ANTITANK 

PRECISION 

TELESCOPE 

HEP 

1500 

METERS 

NIGHT 

FLARE 

be  able  to  monitor  various  switches,  controls,  and  simulated 
turret  and  cupola  positions.  In  addition,  a  substantial 
amount  of  performance  of  task  activity  is  through  voice 
controls.  This  latter  capability  implies  the  need  for  either 
a  manual  or  automatic  mechanism  by  which  the  computer  can 
understand  voice  commands  given  by  the  commander  and  re¬ 
sponses  provided  by  the  remainder  of  the  crew.  One  method 
for  implementation  would  be  to  provide  the  system  operator 
with  a  voice  command  consent  switch  and  by  monitoring  the 
crew  conversations  and  hearing  the  correct  commands  could 
key  in  either  a  code  or  a  number  related  to  a  list  on  a  CRT 
page  or  a  placard  indicating  which  message  was  transmitted. 

An  alternative  would  be  to  provide  an  automated  voice 
recognition  system  which  would  have  a  limited  vocabulary 
but  one  which  would  be  sufficient  for  the  types  of  commands 
given  in  these  scenarios.  Then  the  computer  would  make 
decisions  based  on  the  inputs  received  through  this  system. 
There  is,  however,  a  simple  method  which  may  prove  to  be 
totally  adequate  for  a  performance  monitoring  type  system; 
one  which  does  not  analyze  individual  crew  responses  in 
determining  correct  actions  but  observes  the  overall  problem. 

Each  engagement  in  a  total  problem  can  be  considered  some¬ 
what  like  a  procedure  in  which  some  general  activities  such 
as  maneuvering,  acquiring  line-of-sight,  and  recognition  of 
a  target  may  occur.  A  further  sequence  involves  aligning 
and  loading  the  proper  weapon,  firing  and  observing  the  first 
round,  and  completing  the  engagement  by  firing  the  second 
round.  Since  it  appears  that  the  overall  requirements  of 
the  tank  crew  are  to  acquire  targets  as  soon  as  possible 
and  fire  the  first  round  within  a  period  of  seconds,  and 
then  fire  the  second  round  in  another  period  of  time,  a 
performance  monitoring  system  which  could  provide  displays 
of  these  key  activities  would  provide  observers  with  infor¬ 
mation  on  overall  performance.  Alternatives  to  this  approach 
would  include  monitoring  all  activities  in  the  vehicle 
(switches  and  controls)  and  printing  out  event  times  on-line 
in  real  time  as  the  actions  occur  and  then  scoring  weapons 
firing.  Systems  like  this  have  been  implemented  in 
previous  simulators.  The  overall  result  of  these  was  to 
provide  confusing  data  and  extensive  hardcopy  printout  that 
was  seldom  used.  The  philosophy  that  must  be  employed  is  to 
use  the  capacity  of  the  digital  computer  available  to  assist 
the  instructors  in  performing  performance  monitoring  tasks. 


One  other  major  aspect  that  must  be  considered  is  the  needs 
of  the  experimenter.  In  order  to  perform  experiments  in 
training  research,  it  is  necessary,  not  only  to  have  all 
the  facilities  available  to  the  FCIS  instructor,  but  to 
also  have  the  same  capabilities  available  to  a  general 


training  researcher.  In  this  light,  one  can  think  of  the 
instructor's  performance  monitoring  requirements  as  a  sub-set 
of  the  experimenter's  performance  monitoring  requirements. 

Thus,  the  researcher's  requirements  impose  more  severe 
performance  requirements  on  this  system.  As  a  research  tool, 
the  FCIS  must  be  capable  of  exploring  such  issues  as  the  need 
for  and  extent  of  kinesthetic  cues ,  variability  of  visual 
cues,  and  information  feedback  requirements  for  students, 
use  of  various  instructional  strategies  in  teaching  tasks 
related  to  FCIS  operations,  etc.  Assuming  that  the  experimen¬ 
ter  will  have  all  the  instructor's  capabilities,  the  issues 
to  be  addressed  here  would  include  those  above  and  beyond 
the  training  performance  monitoring  requirement.  The  FCIS 
real-time  simulation  programs  will  generate  a  vast  amount  of 
data  that  can  be  handled  in  one  of  two  ways.  Data  could  be 
stored  away  on  some  mass  storage  medium  for  later  processing, 
analyzing  and  evaluation,  or  it  can  be  analyzed  by  the 
computer  in  real  time  and  displayed  to  the  researcher.  It 
is  essential  that  both  of  these  capabilities  be  provided, 
and  because  of  the  advanced  capabilities  of  current  computer 
technology  and  software  languages,  providing  these  capabili¬ 
ties  does  not  require  a  substantial  cost  increase.  The  simplest 
means  of  storing  large  amounts  of  data  for  later  output  or  pro¬ 
cessing  would  be  to  use  the  capabilities  of  random  access,  mass 
storage  disk  file,  or  a  magnetic  tape  unit.  Data  would  be 
stored  on  a  time  base  with  the  experimenter  defining  system 
characteristics  such  as  the  amount  of  data  to  be  stored, 
data  sampling  rate,  and  length  of  cime  the  data  should  be 
stored.  Being  stored  in  accessible  files  on  either  disk  or 
tape,  batch  programs  could  be  used  to  process  data  to  provide 
line  printer  output  or  curves  in  processed  form.  A  more 
stringent  application  would  be  the  real-time  processing  of 
data  to  provide  instantaneous  analysis  of  problem  development. 
The  problem  formulation  system  data  transformation  algorithms 
can  be  generated  and  stored  as  relocatable  Fortran  modules  to 
be  activated  as  overlays  in  real  time.  Measures  such  as  RMS 
values,  maximum  values,  average  values,  etc.,  could  be 
programmed  in  Fortran  and  stored  in  this  manner.  Upon 
activation,  these  programs  would  monitor  any  simulator 
variables  assigned  and  provide  the  results  as  CRT  displays 
or  possibly  as  plots.  The  instructor  and  the  experimenter 
must  be  provided  with  overall  performance  monitoring  capa¬ 
bilities.  The  instructor  requirements  include  observation 
of  individual  and  interactive  crew  tasks.  The  concept 
using  a  simulated  procedures  monitoring  system  as  mentioned 
earlier  appears  to  provide  a  succinct  assessment  of  per¬ 
formance  that  would  be  relevant  for  the  type  of  training 
on  going  in  FCIS.  For  the  experimenter,  the  system  must 
be  expanded  to  include  real-time  storage  of  large  amounts 
of  data  and  on-line  analysis  of  that  data  for  display  to 
the  instructor. 
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11.1.4.4  Briefing/Debriefing.  Since  the  recommended 
approach  for  trainee  briefing  involves  personal  contact 
between  instructor  and  trainees,  no  instructional  development 
or  additional  study  effort  is  required. 

The  instructor  requires  permanent  recordings  of  performance 
results  in  a  form  suitable  for  debriefing  and  record-keeping. 
The  capability  to  hardcopy  instructor  displays  has,  in  the 
past,  provided  an  efficient  and  cost-ef fecitve  approach  to 
debriefing  requirements.  The  type  of  display  (raster  or 
plasma)  to  be  selected  for  the  instructor  station,  mav  affect 
the  implementation  method  selected  for  hardcopy  although 
the  instructor  control  of  hardcopy  will  be  independent  of 
the  final  approach.  In  many  Link  simulators,  hardcopy 
printout  of  any  instructional  system  display  may  be  obtained 
by  identifying  the  display  (function  switch  for  each  display) 
and  activating  the  hardcopy  function  switch. 

If  a  raster  display  system  is  utilized,  an  image  of  the  display 
page  code  will  be  transferred  to  a  hardcopy  buffer  area  in 
the  computer  memory  for  output  to  the  hardcopy  device.  A 
control  program  is  used  to  queue  requests  and  provide  the 
necessary  interface  signals  required  so  that  output  to  the 
hardcopy  device  proceeds  in  an  efficient  manner.  Hardcopy 
units  for  raster  displays  are  commercially  available.  Link 
has  used  Tektronix  copiers  with  Aydin  Controls'  CRT  displays 
on  several  flight  simulators  and  is  familiar  with  the  inter¬ 
facing  requirements  to  provide  remote  control  of  the  hard¬ 
copy  unit  from  the  instructor  station. 

A  hardcopy  unit  for  a  plasma  panel  display  will  soon  be 
commercially  available.  Current  information  indicates  that 
it  would  operate  in  a  manner  similar  to  the  hardcopy  unit 
with  a  raster  display. 
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11.1.4.5  Demonstrations.  Demonstration  teaching  is  one  of 
the  oldest  techniques  used  in  training.  Demonstrations  are 
used  to  familiarize  the  student  with  a  sequence  of  events, 
peculiar  problems,  and  performance  standards  associated 
with  tasks.  They  are  especially  valuable  where  the  object 
of  learning  involves  operation  of  a  complex  system  in  a 
hostile  environment.  Demonstrations  can  be  a  convenient 
way  of  illustrating  the  interdependencies  between  the 
weapons  systems  and  the  technical  environment,  and  in 
defining  the  tactical  decision  making  process  involved  in  a 
particular  situation. 

The  trainer  record/playback  capability,  particularly  the 
software  programs,  can  with  minor  extensions,  be  used  to 
provide  demonstration  capability.  A  demonstration  is 
simply  a  permanent  record/playback.  Once  generated,  they 
would  be  stored  on  disk  and  selected  and  activated  by  the 
instructor  via  the  display/control  system  keyboard.  It 
would  be  possible  to  create  tape  libraries  of  demonstrations 
if  the  number  of  demos  exceeds  the  allocated  disk  space. 

Automated  demonstrations  provide  a  standardized  method  of 
instruction  and  elevate  the  instructor  role  to  that  of 
observer,  affording  him  more  time  to  advise  and  comment 
on  the  different  technical  situations  presented  to  the  crew 
members.  Demonstration  capability  would  enhance  training 
effectiveness  of  the  FCIS-LM  device  with  an  insignificant 
impact  on  cost;  and  therefore  it  should  be  included. 

Based  on  the  relatively  short  engagements  in  tank  warfare, 
a  maximum  length  of  two  minutes  per  demonstration,  and  a 
total  of  twenty  demonstrations  should  provide  an  adequate 
variety  of  engagements.  Due  to  their  brevity,  no  internal 
reset  points  are  required.  Once  initiated,  the  demonstra¬ 
tion  would  run  to  completion,  although  it  will  be  possible 
to  "freeze"  the  demonstration  at  any  point. 

11.1.4.6  Scoring.  Scoring  algorithms  provided  must  be 
applicable  to  typical  problems  such  as  those  outlined  in 
section  5.2.1  (Scenarios  of  Engagements).  Algorithm 
scoring  can  also  be  incorporated  by  using  the  problem 
formulation  system.  For  each  type  of  engagement,  a 
separate  performance  measurement/scoring  algorithm  could 
be  provided  and  programmed  in  Fortran.  Initiation  of  the 
engagement  would  also  activate  the  performance  measurement 
algorithm,  which  in  turn  would  monitor  the  engagement 
activity,  and  provide  results. 
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At  this  stage  in  the  study  program  it  is  somewhat  difficult 
to  detail  the  elements  of  the  algorithms.  Many  issues  remain 
unsettled  in  terms  of  assessment  of  tank  crew  performance; 
e.g.,  does  one  address  only  the  performance  of  the  crew  in  its 
entirety  or  each  individual  member,  providing  scores  for  each 
crew  member  or  for  the  entire  crew.  Also,  is  the  tank  command¬ 
er,  being  ultimately  responsible  for  that  behavior  of  the  tank 
and  crew  scored  without  regard  to  the  actions  of  others.  The 
capabilities  provided  by  a  system  of  this  kind  are  innumerable. 
As  long  as  data  is  available  in  the  computer,  the  overlayable 
engagement  scoring  algorithms  can  monitor  procedural  actions, 
time  based  performance  and  instantaneous  measurements,  such 
as  miss  distance.  These  separate  scoring  elements  can  then 
be  combined  into  final  scores  for  engagements.  The  system 
envisioned  would  also  allow  for  on-line  update  and  generation 
of  the  overlay  algorithms  and  from  this  standpoint  can  be 
considered  as  a  computer  program.  The  result  is  that  system 
capability  and  flexibility  would  be  limited  by  only  two 
things:  a)  the  capability  of  the  digital  computer  to  per¬ 
form  certain  computations  and  keep  track  of  certain  events, 
and  b)  the  imagination  of  the  user. 

11.1.4.7  Record/Playback  Audio.  In  the  simulated  M60A3 
environment  where  many  crew  actions  are  based  on  voice 
commands  and  responses,  a  record/playback  system  with  synchron¬ 
ized  audio  will  provide  valuable  information  to  the  instructor 
critiquing  crew  interaction.  Link  recognizes  the  value  of 
record/playback  audio  and  has  provided  both  record/playback 
and  demonstration  audio  on  a  variety  of  simulators  and  con¬ 
siders  it  an  important  requirement  for  the  FCIS-LM  device. 

One  approach  for  implementing  the  record/playback  audio 
system  requirement  was  an  Emerson  Electric  four-track  tape 
transport  and  electronic  assembly  supplied  by  Telemetry 
Systems  Engineering.  This  system  is  referred  to  as  the  Quick 
Access  Audio  Cartridge  System  (QUAACS) .  Multitrack  audio 
tape  heads  permit  selective  track  recording  or  playback  and 
single-track  signal  erasure  while  recording.  The  system 
allows  the  user  to  record  and  playback  audio  data  at  15/16 
inches  per  second.  QUAACS  permits  the  rapid  search  of  a 
magnetic  tape  cartridge  at  120  inches  per  second  by  a  digital 
computer.  This  system  can,  under  computer  control,  meet  the 
access  requirements  for  30  one-minute  playback  segments  and 
also  provide  continuous  recording  of  up  to  30  minutes  of  the 
training  exercise  audio. 

Another  record/playback  audio  approach  involves  use  of  multiple 
tape  cartridge  machines  of  the  type  manufactured  by  Broadcast 
Electronics  <BE) .  A  full  range  of  record  and  playback  units 
is  available  and  Link  has  used  a  number  of  different  models 
for  various  simulator  applications.  The  FCIS  application  will 
require  a  cartridge  machine  with  both  record  and  playback  capa- 


11-28 


bility  from  the  BE  Series  3000.  Normal  tape  speed  is  7.5  ips 
and  the  optional  fast  forward  speed  is  22.5  ips;  remote  con¬ 
trol  capability  is  available.  To  meet  a  ' ready-for-playback ' 
requirement  of  30  seconds  or  less  the  system  would  require  a 
15  unit  configuration.  The  cost  of  this  configuration  is  high 
and  further  analysis  to  determine  if  an  alternate  configuration 
of  10  units  at  half  the  cost  and  providing  the  same  training 
capability  but  requiring  a  40  second  delay,  is  necessary. 

A  third  approach  to  providing  record/playback  audio  employs 
a  very  simple  digital  voice  technique.  During  the  record 
mode  the  crew  voices  are  converted  from  analog  into  digital 
form  and  stored  on  the  disk;  in  playback  the  digital  data  is 
converted  back  to  analog.  This  approach  storage  limited  only 
by  the  amount  of  disk  space  allocated.  Access  time  for  disk 
data  is  negligible.  The  audio  reproduced  by  the  digital 
technique  may  not  have  the  same  level  of  fidelity  to  human 
speech  as  the  previously  described  tape  systems  provide. 
Although  a  digital  voice  system  is  not  commercially  available 
at  this  time,  the  approach  is  extremely  attractive  and  Link 
is  presently  investigating  commercially  available  components 
to  configure  such  a  system.  Link  is  also  conducting  an  in- 
house  design  effort  in  order  to  provide  a  digital  voice  sys¬ 
tem  as  part  of  a  current  contract. 

All  three  approaches  described  could  be  used  to  meet  the 
FCIS  record/playback  audio  requirement  and  will  be  considered 
in  design  tradeoff  selections  in  the  following  sections  of 
this  report. 

11.1.5  System  Design  Tradeoff  and  Selection  .  This  section 
presents  tne  detailed  tradeoff  analysis  required  to  select 
an  approach  for  the  display  system  and  the  record/playback 
audio  system.  Performance  parameters  for  each  system  were 
identified  and  assigned  weighting  factors.  The  evaluation 
factor  (EF)  represents  the  capability  of  the  candidate 
approach  to  meet  the  performance  parameter.  A  high  EF  number 
indicates  better  performance. 

11.1.5.1  Display  System.  The  display  system  for  the  FCIS 
will  provide  instructor  control  of  the  training  problem  as 
well  as  vehicle  position  chart  display  capability.  As  indi¬ 
cated  in  previous  sections  the  candidate  approaches  have  been 
narrowed  to  two  for  further  evaluation;  i.e.,  raster  display 
and  plasma  display. 

Five  performance  parameters  were  identified  for  the  display 
system.  Color  was  selected  as  a  performance  parameter  since 
a  color  display  provides  greater  information  density,  encoding 
capability  and  message  categorization;  e.g.,  green  for  in¬ 
structor  alerts.  The  hardcopy  capability  is  a  statement  of 
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work  requirement.  The  EF  was  used  in  this  case  to  indicate 
the  availability  of  a  hardcopy  device  for  each  approach  as 
well  as  Link's  experience  with  it.  Display  update  speed  is 
a  measure  of  the  system's  capability  to  present  new  data  for 
display.  Indicator  size  reflects  the  availability  of  differ¬ 
ent  size  displays  at  the  instructor's  station.  Computer 
impact  provides  an  indication  of  the  extent  of  the  interface 
necessary  between  the  display  system  and  the  main  computer 
complex,  both  hardware  and  software.  In  this  case,  the 
lower  the  computer  impact  received,  the  higher  the  rating; 
so  that  the  higher  EF  number  always  indicates  superior  per¬ 
formance.  As  a  result  of  the  evaluation  shown  in  Table 
11-3,  the  raster  display  has  been  selected  for  the  instructor 
station  display  system.  Although  the  scores  were  close, 
subjective  opinion  reinforces  its  selection.  Although  the 
plasma  display  represents  a  technologically  simple  approach 
and  is  very  attractive  from  a  reliability /maintainability 
(R  &  M)  standpoint,  the  question  of  future  plasma  panel 
availability  is  serious  enough  to  discount  this  approach. 

11.1.5.2  Record/Playback.  Three  candidate  approaches  for 
record/playback  audio  were  described  in  Section  11.1.4.7. 

Three  performance  parameters  were  defined.  Access  time  rep¬ 
resents  the  ability  of  a  system  to  be  ready  for  playback  in 
the  time  allotted  in  the  statement  of  work  (30  seconds  or 
less) .  Recording  time  is  the  amount  of  available  time  in  the 
proposed  system.  The  quality  of  voice  represents  the  system's 
reproduction  fidelity. 

As  a  result  of  the  analysis  detailed  in  Table  11.4  the 
digital  voice  technique  has  been  selected  to  implement  the 
record/playback  audio.  Although  the  digital  voice  technique 
involves  a  development  effort,  its  simplicity,  high  relia¬ 
bility,  and  resulting  low  life-cycle  cost  (LCC)  will  make  a 
significant  contribution  to  state-of-the-art  training 
technology. 

11.1.6  Instructor  Station  Configuration.  The  FCIS-LM 
device  is  configured  with  two  separate  crew  training  stations, 
one  for  the  driver  and  one  for  the  crew  in  the  turret  (the 
commander,  gunner  and  loader) . 

11.1.6.1  Instructor  Observation  Stations.  Instructor/ 
Observer  positions  at  both  training  stations  have  been 
located  on  the  motion  platform,  behind  the  crew  member (s) 
so  that  the  actions  of  the  crew,  control  and  instrument 
status,  and  a  proper  perspective  of  the  visual  scene  may 
be  observed  during  training  (figures  11-2  and  11-3)  . 

Due  to  cost  considerations,  the  instructors  will  have  no  CRT 
and  minimal  controls  on  the  motion  platforms,  but  will 
effect  control,  monitoring  and  evaluation  inputs  via  intercom 
to  an  instructor  with  full  controls  at  the  main  instructor/ 
experimenter  station.  At  both  instructor /observer  stations 
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TABLE  11-4  TRADEOFF  ANALYSIS  CHART  RECORD/PLAYBACK  AUDIO  FUNCTION 
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EVER 

TROL/DISPLAY 

IEL 


iTRUCTOR 


there  will  be  controls  to: 

o  Cutoff  power  to  the  entire  complex  (emergency  only) ; 
o  Freeze  or  unfreeze  the  training  problem; 
o  Turn  the  motion  system  on  or  off; 
o  Operate  the  instructor's  intercom  system. 


The  instructors  will  also  have  indicator  lights  showing  the 
status  of  all  safety  interlocks  associated  with  the  motion 
system.  All  of  these  controls  and  indicators  will  be 
visible  and  within  reach  of  the  tank  commander  or  driver 
(as  appropriate) ,  should  training  be  conducted  without  an 
instructor  present  on  the  motion  platform. 

11.1.6.2  Main  Instructor/Experimenter  Station.  The  main 
instructor/ experimenter  station  will  be  located  in  the 
computer  room.  A  conventional  instructor  station  layout  and 
structure  will  be  used,  having  four  (4)  CRT  displays.  (See 
figure  11-4) .  The  leftmost  display  will  be  a  visual  system 
monitor  for  the  gunner's  or  the  commander’s  optical  or  I.R.  sys 
terns.  Below  this  display  are  the  controls  to  select  either  gun 
ner  or  commander  visual  sight  functions.  When  "Gunner"  is  se¬ 
lected,  whichever  system  the  gunner  is  using  will  be  displayed, 
with  reticle  when  appropriate  (the  default  will  be  his  IX  peri¬ 
scope)  .  When  "Commander"  is  selected,  the  results  will  be  the 
same,  except  the  default  will  be  his  8X  system. 

The  second  display  will  repeat  any  one  of  the  four  fighting 
station  visual  channels  or  any  of  the  two  driver  station 
visual  channels.  The  selection  controls  are  located  directly 
below  this  repeater. 

The  third  display  is  the  instructors  primary  alphanumeric/ 
tactical  map  CRT.  From  this  position,  using  the  controls 
mounted  below  the  CRT,  the  instructor  is  able  to  perform  all 
of  the  necessary  instructor  functions,  including  problem 
initialization  and  control,  selection  and  activation  of  the 
automated  training  features,  calls  for  hardcopy  printout  and 
operate  the  intercom.  In  the  'MAP'  mode,  the  instructor 
will  be  able  to  observe,  as  though  from  above,  the  entire 
battle  area  complete  with  significant  terrain  features  and 
the  position  and  movement  of  all  friendly  and  threat  forces. 

The  fourth  display  is  for  the  instructor's  use  during  complex 
operations.  It  will  allow  him  to  simultaneously  display  a 
map  and  a  problem  control  format.  This  display  is  also  used 
by  an  experimenter  during  research.  Below  this  display 
are  mounted  controls  for  altering  and  adapting  the  various 
systems  and  capabilities  during  research  and  for  controlling 
specialized  monitoring,  control,  scoring,  recording,  and  eval¬ 
uating  CRT  formats. 
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Figure  11-4  FCIS-LM  Instructor/Experimenter  Station 


11.1.7  Instructional  Features. 

11.1.7.1  Instructor  and  Experimenter  Control/Display 
Medium.  Ins true tor/experimenter  control  and  display 

functions  can  be  implemented  with  the  same  type  hardware  as 
the  Vehicle  Position  Chart)  (VPC) .  This  approach  is  based 
on  the  preliminary  trade-offs  which  established  the  flat 
panel  display  and  the  raster  scan  CRT  system,  as  the  candidate 
systems  for  both  requirements.  Further  analysis  led  to  the 
selection  of  the  raster  CRT  display.  Two  typical  systems  are 
shown  in  figures  11-5  and  11-6. 

Either  of  the  systems  illustrated  has  the  capability  to  dis¬ 
play  computer  generated  symbology  in  tabular  or  graphic  form. 

In  addition,  through  additional  electronics,  video  images  of 
gaming  area  maps  may  be  mixed  with  the  computer-generated 
video  signals  to  form  composite  images.  This  display  system 
would  meet  the  FCIS-LM  display  and  control  requirements  by 
operating  in  two  modes.  One  mode,  being  MAP  or  the  VPC,  and 
the  other,  which  is  of  more  interest  in  this  section,  is  the 
problem  monitoring  and  control. 

The  recommended  system  utilizes  alphanumeric  page  formats, 
where  each  page  contains  fixed  text  (descriptions,  units,  etc.) 
and  variable  data  (current  value  of  simulation  variables) . 

Pages  are  organized  according  to  functions;  e.g.,  system 
malfunctions,  weapons  delivery,  etc.  In  essence,  this  system 
performs  two  functions.  First,  data  in  the  simulation  data- 
pool  is  displayed  to  the  user  and,  second,  keyboard  inputs 
modifying  that  data  are  inserted  into  the  datapool.  (It 
should  be  noted  that  these  systems  do  have  limited  graphics 
capability,  but  displays  can  be  formatted  in  that  manner,  if 
required. ) 

Since  these  functions  are  general  in  nature,  a  functional 
specification  for  a  software  package  to  drive  these  displays 
can  also  be  formulated. 

A  page  preparation  program  should  be  provided  so  that  the 
operator  has  a  means  of  generating  or  changing  any  CRT  page 
provided  with  the  FCIS  simulator.  The  page  should  be 
generated  on  the  actual  CRT  at  the  Instructor  Station. 

The  CRT  page  may  be  made  up  of  any  combination  of  fixed  words 
and  phrases,  and  computer-supplied  responses.  The  page 
format  should  make  the  following  provisions: 

a)  Lines  must  be  available  for  alerts  and  inputs. 

b)  Space  must  be  allowed  for  ten  digits  of  computer- 
supplied  values. 
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Figure  11-5  FCIS-LM  Instructor/Experimenter  Display  System  (Example  1) 


c) 


No  more  than  80  computer  responses  can  be  placed  on 
a  CRT  page. 


Once  a  page  has  been  selected  for  change  or  generation, 
the  program  will  enter  a  generation  mode.  While  in  this 
mode,  the  instruction  page  will  be  displayed  on  one  CRT 
(the  second  A/N  CRT  at  the  IOS  which  displays  pages)  and 
the  page  being  changed  or  generated  will  be  displayed  on  the 
other  (the  A/N  CRT  which  displays  keyboard  entries  at  the 
IES) .  Keyboard  control  will  automatically  transfer  to  the 
appropriate  CRT.  Any  keyboard  entry  from  the  IES,  while 
in  the  generation  mode,  will  be  processed  as  an  entry  to 
this  CRT  and  will  be  accepted  as  a  CRT  page  change. 

Figure  11-7  illustrates  the  generation  mode  format  of  a 
page,  and  figure  11-8  illustrates  how  the  page  displays 
the  desired  values. 


When  the  manual  page  program  has  completed  processing  the 
information  transmitted  to  it  by  XMIT  P.PAGE,  it  will  display 
the  generated  page  with  all  computer  response  areas  blank 
(the  processing  may  take  more  than  one  minute) .  If  an  un¬ 
defined  program  symbol  has  been  detected,  the  word  ERROR 
will  appear  instead  of  the  blank  area.  ERROR  will  become 
a  permanent  word  and  remain  on  the  page  until  the  operator 
takes  appropriate  action  to  correct  it. 


<MTIME> 
«ATIME> 
«01ENGAGE  > 
•*02TGTNO  > 
<AZIM> 

<  ELEV> 
<HDG> 


SECONDS 

SECONDS 


DEGREES 

DEGREES 

DEGREES 


MISSION  TIME 

TIME  SINCE  ENGAGEMENT  START 
INITIATE  NEW  ENGAGEMENT 
NEW  TARGET 

TURRET  AZIMUTH  (FROM  TGT) 
TURRET  ELEVATION 
TRUE  HEADING 


Figure  11-7 


Typical  CRT  Page  Generation  Mode  Format 
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240.4 

SECONDS 

MISSION  TIME 

1.8 

SECONDS 

TIME  SINCE  ENGAGEMENT 
START 

01 

FALSE 

INITIATE  ENGAGEMENT 

02 

04 

NEW  TGT 

74 

DEGREES 

TURRET  AZIMUTH  (FROM 
TGT) 

4 

DEGREES 

TURRET  ELEVATION 

190 

DEGREES 

TRUE  HEADING 

Figure  11-8  Re-generated  CRT  Page  Display 


In  general  terms,  the  program  processes  the  information  by 
looking  up  the  symbol  in  the  symbol  dictionary  to  find  its 
address,  type,  precision,  scale  factor,  etc.,  as  appropriate. 
It  files  the  information  in  an  eighty  double-word  table 
assigned  to  that  particular  page.  This  implies  two  things. 
First,  the  information  in  the  symbol  dictionary  must  be 
complete  and  accurate.  Second,  no  more  than  80  computer 
responses  may  be  requested  for  any  page. 

The  computer  response  information  is  placed  into  the  table 
by  separate  schemes  for  numbered  and  unnumbered  entries. 
Numbered  entries  are  placed  in  the  table  from  the  top  down 
in  their  numbered  spot.  The  unnumbered  entries  are  placed 
in  the  table  from  the  bottom  up  according  to  the  time  order 
in  which  they  are  processed.  It  is,  therefore,  important 
that  when  both  numbered  and  unnumbered  computer  responses 
appear  on  a  page  together,  the  numbered  items  start  around 
01  and  advance  through  the  low  numbers. 

11.1.7.2  Malfunctions.  The  FCIS  training  is  orientated 
toward  combat  crew  interactions  and  tactics.  Malfunction 
capabilities  should  be  designed  to  provide  training  in  over¬ 
coming  failure  of,  or  casualties  to  critical  systems,  and 
the  continued  ability  to  fight  quickly  and  effectively. 
Following  is  a  list  and  description  of  system  failures  which 
impact  the  tactical  performance  capabilities  of  the  crew  and 
which  can  be  remedied  or  worked  around  without  dismounting. 

a)  Tank  immobilized  (engine  running)  -  such  as  a  broken 
track,  or  drive  train  component. 
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b)  Electrical  failure  -  (requiring  sparing  battery 
usage  or  manual  traverse,  firing  and  so  forth). 

c)  F . 62  coaxial  machine  gun  jammed. 

d)  .50  caliber  machine  gun  jammed. 

e)  Round  will  not  fire  -  main  gun 

f)  Ballistic  computer  failure 

h)  Engine  failure  (as  a  result  of  a  hit  or  a  fuel  or 
oil  system  failure) 

i)  Stabilization  system  failure  (Azimuth) 

j)  Stabilization  system  failure  (Elevation) 

k)  Stabilization  system  failure  (Analog  drift,  dc 
rate  drift) 

l)  Breech  hydraulic  damper  failure  (breech  hang  up) 

m)  Main  gun-no  ejection,  or  partial  ejection. 

n)  Safety  circuit  failure  -  main  gun 

o)  Laser  rangefinder  failure 

p)  Intercommunications  sytem  failure 

q)  Radio  failure 

Malfunctions  for  FCIS  should  be  both  manual  and  automated 
(via  preprogramming) .  The  instructor  must  have  the  capa¬ 
bility  to  manually  identify,  insert  or  remove  malfunctions 
via  display  page  and  keyboard  interaction.  Since  the 
number  of  FCIS  malfunctions  is  relatively  small,  all  mal¬ 
functions  could  be  displayed  on  one  page.  Each  malfunction 
would  be  assigned  an  identification  number;  malfunctions 
currently  active  would  be  designated  bv  a  svmbol  next  to  the 
malfunction  number.  TvDically.  malfunctions  are  manuallv 
inserted  in  one  of  two  ways.  If  the  malfunction  number  is 
known  by  the  instructor,  he  may  sinmlv  key"  MALF",  the 
malfunction  number,  and  "INSERT".  When  this  method  is  used, 
no  display  page  changes  will  take  place,  thus  allowing  the 
instructor  to  continue  monitoring  the  currently  displayed 
page.  Deletion  of  malfunctions  is  accomplished  by  keying 
"MALF",  the  malfunction  number,  and  "DELETE".  To  identify 
malfunctions  when  the  desired  malfunction  number  is  known, 
the  malfunction  page  would  be  selected  by  keying  "MALF"  and 
"DISP" .  At  that  point  the  instructor  needs  only  to  key  in 
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the  malfunction  identification  number  and  "INSERT". 

The  FCIS  instructor  should  also  have  the  capability  to 
preprogram  malfunctions  for  automatic  insertion.  When  a 
mission  is  formulated  malfunctions  can  be  planned  to  occur 
at  a  particular  time  or  when  a  particular  set  of  conditions 
or  event  exists,  e.g.,  when  an  enemy  tank  fires  at  own  tank, 
the  main  gun  round  will  not  fire.  During  the  mission  the 
instructor  can  concentrate  on  his  main  tasks  of  monitoring 
and  evaluating  the  crew  without  being  distracted  by  the 
requirement  to  insert  a  malfunction  at  a  particular  time. 

Conditions  for  malfunction  insertion  will  be  written  in 
FORTRAN  in  an  IF....,  THEN. ...  format .  Some  detail  on 
preprogramming  malfunctions  is  presented  in  section  11.1.7.4. 

11.1.7.3  Record/Playback.  The  recommended  approach  to 
record/playback  is  to  record  inputs  and  selected  internal 
variables  as  discussed  in  Section  11.1.4.2.  Implementation 
of  this  approach  was  also  described  in  detail  in  that 
section.  Record/playback  control  will  be  provided  via  in¬ 
structor  station  display  and  keyboard.  The  instructor  will 
initiate  the  recording  mode  by  activating  a  switch.  Due  to 
the  limited  duration  of  a  typical  tank  engagement  a  recording 
will  be  automatically  terminated  after  1  minute.  The  in¬ 
structor  will  have  the  capability  to  record  thirty  segments. 
Segments  will  be  selected  for  playback  from  a  display  page. 
Each  recorded  segment  will  be  identified  by  a  mission  elapsed 
time  (MET)  so  that  the  instructor  will  have  a  frame  of 
reference  from  which  to  select  a  segment  for  playback.  Each 
recording  would  be  automatically  time  tagged  and  entered  into 
the  first  available  segment  identification  slot  on  the  display 
page  along  with  its  MET. 

11.1.7.4  Problem  Formulation  and  Control.  Most  of  the 
features  described  in  the  preceding  sections  can  be  imple¬ 
mented  automatically,  during  operation,  using  the  preprogram¬ 
ming  capability.  The  design  objectives  for  this  system  were 
to  provide  the  appropriate  capabilities  in  such  a  way  as  to 
allow  sophisticated  research  capabilities  in  training  tech¬ 
nology  utilizing  a  library  of  automated  exercises,  and  to 
allow  ease  of  operation  for  users  not  proficient  in  computer 
programming . 

To  do  this,  two  design  problems  must  be  addressed.  The  first 
is  to  provide  a  flexible  system  that  can  easily  perform  the 
required  functions  during  real  time  operation,  and  allow  new 
problems  to  be  generated,  or  modifications  made  to  existing 
problems,  through  the  instructor’s  CRT  and  keyboard  controls. 
The  second  design  problem  is  to  provide  an  interface  language 
that  is  usable  by  personnel  who  are  completely  inexperienced 
in  computer  programming. 
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The  preprogramming  system  should  allow  the  user  to  develop 
a  library  of  exercises  (see  Figure  11-9)  where  each 
exercise  consists  of  a  table  that  defines  a  minimum  of  one 
and  a  maximum  of  twelve  exercise  segments.  Each  exercise 
segment  should  have  associated  with  it  a  table  which 
defines  a  maximum  of  fifteen  cases.  The  system  stores  ex¬ 
ercise  tables,  task  tables,  and  cases  on  a  disk  file,  once 
they  are  created.  This  makes  it  very  easy  to  modify  any 
element  within  the  exercise  structure.  When  any  of  these 
elements  are  created,  an  index  page  assoicated  with' the 
element  is  updated,  so  the  user  has  the  capability  of 
looking  at  an  index  of  the  exercise  tables,  exercise  segment 
tables,  or  cases.  After  creation  or  modification  of  an 
exercise  table,  the  complete  exercise  is  compiled  and 
cataloged  (at  exercise  segment  level) .  Each  segment  of  the 
exercise  will  be  resident  on  the  disk  as  an  object  module, 
which  is  overlayable  into  core  and  executeable. 

The  preprogramming  system  consists  of  a  group  of  low-priority, 
non-real-time  foreground  programs.  The  primary  program 
should  be  interactive  with  the  alphanumeric  CRT.  This 
program  allows  development  of  exercises  and  setting  up 
specific  core  tables  when  a  request  is  made  for  execution  of 
a  particular  exercise.  Another  program  has  the  task  of  per¬ 
forming  th  loading  of  the  absolute  overlays  (exercise  segment 
object  code)  when  an  exercise  execution  is  requested. 

The  selection  of  a  high  order  language  permits  the  solving  of 
most  of  the  user  interface  problems.  First,  many  of  the  inter¬ 
ested  users  are  technically-oriented  instructors  and  are 
probably  familiar  with  FORTRAN.  The  simplicity  of  much  of 
the  coding  requires  virtually  no  learning  for  those  who 
might  be  unfamiliar  with  the  language.  The  incorporation  of 
preformatted  pages  can  make  the  use  even  simplier.  Each 
input  page  encountered  by  the  user  contains  all  syntax-re¬ 
quired  data  as  well  as  structured  statements  requiring  only 
data  that  is  specific  to  desired  results. 
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Figure  11-9  Typical  Preprogramming  Structure 


11-45 


One  of  the  requirements  noted  earlier  was  that  the  system 
should  be  interactive.  The  system  is  designed  to  lead  the 
user  through  the  steps  and  processes  required  for  each 
phase  of  input.  During  exercise  generation  or  modification, 
both  alphanumeric  CRT's  and  the  associated  keyboard  are 
employed.  Instructions  appear  on  one  CRT,  while  computer 
requests  for  user  inputs  and  user  responses  appear  on  th 
other  CRT.  All  user  inputs  are  made  via  the  keyboard  once 
the  mode  is  activated. 

All  software  inputs  needed  to  satisfy  structural  aspects 
of  the  exercises  are  preformatted  with  the  user  entering 
specific  data  such  as: 

1)  Record  Titles*.  The  system  as  mentioned  is  actually 

a  series  of  files  structured  in  the  following  hierarchy 
exercise,  exercise  descriptions,  exercise  segments, 
and  cases.  Thus,  each  new  record  requires  a  title 
entered  on  the  top  two  lines  of  the  preformatted 
page.  It  should  be  noted  that  an  index  display  is 
provided  as  part  of  the  system.  The  generated  titles, 
as  mentioned  above,  are  automatically  added  to  the 
appropriate  index. 

2)  Record  Numbers:  The  record  numbers  are  the  pointers 
used  by  the  software  in  the  concatenation  process. 

As  each  source  file  is  generated  or  modified,  the 
user  enters  the  number. 

3)  File  Assignments:  The  basic  functioning  syntax  is 
usually  at  the  case  level.  Files  higher  up  in  the 
hierarchy  are  constructed  by  assigning  records  of 
lower  level  files  to  them.  An  exercise  segment  con¬ 
sists  of  a  series  of  up  to  14  cases.  Thus,  to  gener¬ 
ate  a  segment,  the  coding  contains  only  the  text  CASE 
XYZ  (XYZ  is  the  case  record  number) .  The  syntax  CASE 
references  a  file,  and  XYZ  identifies  the  record  number 
in  that  file. 

4)  Conditions  and  Actions:  At  the  case  level,  the  user  is 
generating  conditional  statements  and  action  statements 
For  the  most  part,  this  is  preformatted,  but  when  it 

is  not,  the  user's  guide  describes  the  step  required 
to  perform  the  desired  action.  It  should  be  obvious 
that  the  designers  could  not  predict  all  possible 
combinations  of  condition  statements  and  resulting 
actions.  This  much  is  left  to  the  user. 
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11.1.7.5  Performance  Monitoring  and  Scoring.  In  order  to 
determine  the  appropriate  performance  monitorina  features 
for  the  FCIS-LM  device  it  was  necessary  to  analyze  specific 
tasks  performed.  First,  the  type  of  scenarios  that  the 
crew  will  be  exposed  to  must  be  considered.  Table  11-2 
identifies  several  types  of  engagement  scenarios.  It  should 
be  noted  that  scenario  time  between  engagements  will  not 
require  extensive  monitoring  systems,  if  any,  due  to  the 
nature  of  tasks  performed.  An  analysis  of  those  tasks  and 
the  types  of  skills  required  by  the  crew  is  contained  in 
Section  4,  Tables  4-2  through  4-5.  This  task  and  skill  data 
has  been  used  to  determine  the  approach  to  FCIS-LM  trainee 
performance  assessment.  The  system  features  are  also  based 
on  the  twenty  engagements  described  in  Section  5  and 
identified  in  Table  11-2.  Two  important  aspects  related 
to  crew  performance  assessment.  First,  the  specific 
sequence  of  actions  and  their  correct  application  to  the 
engagement  must  be  evaluated  or  recorded.  The  other  aspect 
is  that  of  total  response  by  the  integrated  crew,  to  the 
problem  presented. 

Since  the  latter  function  requires  more  subjective  judgement 
on  the  part  of  the  instructor,  it  will  be  discussed  first. 

The  overall  engagement  objective  of  the  M60A3  crews  is  to 
seek  out,  identify,  and  destroy  enemy  targets.  All  this  must 
occur  prior  to  the  enemy  performing  the  same.  Ultimately 
then,  the  "true"  measure  of  the  crew's  ability  is  to  survive 
in  the  tactical  environment.  In  order  to  evaluate  this  type 
of  performance  in  the  FCIS  device,  the  entire  problem  must 
be  broken  down  into  two  areas:  1)  engagements  and  2)  non¬ 
engagements  (cross  country,  etc.).  In  cross  country  exercises, 
no  performance  measurement  is  of  any  value  except  in  follow¬ 
ing  correct  paths.  The  more  important  aspect  is  the  end 
result  achieved  by  the  crew  during  specific  enemy  engagements. 

In  analyzing  methods  of  measuring  performance,  two  things 
emerge.  First,  correct  performance  is  a  function  of 
achieving  certain  task  objectives  in  the  proper  time  frame. 
These  are  general  in  nature  and  determine  survivability.  One 
can  view  these  procedurally ;  consider  the  following  steps: 


1) 

-  Target  is  within  visual  acquisition 

2) 

*1 

-  Crew  acquires  target 

3) 

-  Turret  turned  to  TGT  azimuth 

4) 

*3 

-  Ranging 

5) 

*4 

-  Fire  weapon  round  one 

6) 

Kill/Miss 
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7)  tg  -  Fire  weapon  round  two 

8)  Kill/Miss 


The  goal  is  a  first-round  target  hit  in  the  minimum  possible 
time  (FM  17-12) .  For  example,  an  M60-series  tank  moving 
12-15  mph  with  main  gun  loaded  and  laid  no  more  than  15°  off 
target,  range  and  ammunition  indexed  must  be  able  to  engage 
an  armor-type  target  using  battlesight  within  5  seconds 
during  daylight  and  obtain  a  target  hit  within  10  seconds. 

Based  on  time  t^  and  assuming  enemy  performs  correctly, 
assessment  of  performance  is  whether  a  kill  or  miss  is 
obtained. 

Obviously,  a  (probability  of  kill)  would  be  computed  for 
the  appropriate  weapon.  The  recommended  way  of  portraying 
this  to  the  instructor  or  experimenter  is  a  tabular  display 
page  listing  to  through  ts  and  showing  elapsed  time.  A 
display  of  this  might  look  like  the  one  shown  in  Figure  11-10. 

This  display  shows  only  the  results  of  the  engagement.  In 
order  to  evaluate  crew  skills  in  achieving  this  result, 
another  type  of  performance  monitoring  is  required;  one 
which  will  identify  all  activities  occurring  during  engage¬ 
ments.  It  appears  that  the  simplest  approach  would  be  the 
use  of  a  "TIME/EVENT"  monitor.  This  feature  would  monitor 
all  activities,  switches,  controls,  etc.,  in  the  compartment 
and  provide  a  time  based  printout  of  when  each  event  occurred. 

The  key  problem  associated  with  each  of  these  systems  is  to 
initiate  the  monitoring  sequence  at  the  appropriate  point 
in  the  scenario.  This  can  be  done  by  time,  position,  or 
events.  The  first  two  are  specific  but  also  have  serious 
deficiencies.  In  a  time  based  system  where  the  FCIS  crew 
exercises  flexibility  and  their  own  judgement  in  traversing 
the  gaming  area,  it  will  only  be  on  rare  occasions  that  the 
tank  is  at  the  proper  position  for  an  engagement  at  a  speci¬ 
fied  time.  Thus,  the  resulting  monitoring  will  be  in  error. 
Position  would  be  somewhat  more  realistic;  however,  since 
the  crew  has  the  flexibility  to  change  routes,  one  cannot 
be  sure  that  the  crew  will  ever  reach  that  position.  The 
most  promising  approach  then  is  to  define  a  set  of  simulator 
events,  which  could  include  time  and  position,  that  would 
accurately  determine  the  start  of  an  engagement. 
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An  engagement  can  be  considered  to  be  underway  when 
certain  criteria  are  met.  These  are: 

1)  Enemy  target  objective (s)  are  within  visual 
range  and  not  occulted. 

2)  The  threat  imposed  by  the  objective  is  serious 
enough  to  warrant  response. 

The  use  of  a  simulated  visual  scene  poses  serious  problems  in 
making  the  first  determination  above.  This  is  because  occult¬ 
ing  information  is  not  easily  available  from  the  data  base. 

The  flow  chart  shown  in  Figure  11-11  represents  an  approach 
to  solving  this  problem. 


Once  the  start  of  an  engagement  is  defined  (or  computed) ,  the 
two  performance  measurement  schemes  can  be  activated. 
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Figure  11-11  Performance  Monitoring  Start  of  Engagement  Flow  Chart 
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11.2  Computational  Systems 

The  computation  system  requirements  have  been  established 
for  visual  systems,  motion  systems,  crew  station,  vehicle  sys¬ 
tems,  weapons  system,  and  instructional  systems.  Based  on  an¬ 
alyses  of  crew  tasks,  tactical  environment,  available  cue(s), 
and  the  vehicle  performance  envelope,  the  real-time  system 
requirements,  and  the  additional  computer  requirements  for  exe¬ 
cutive  programs,  test  and  diagnostic  programs,  and  off-line 
programs,  can  be  satisfied  by  a  multitude  of  computer  hardware 
configurations  ranging  from  one  very  large  processor  to  a  series 
of  minicomputers  connected  in  a  multi-processor  or  multi-com¬ 
puter  configuration.  Practically  all  large,  real-time,  training 
simulators  use  combinations  of  computers  to  provide  adequate 
computing  power  for  the  total  task.  It  is  anticipated  that, 
in  the  future,  computer  configurations  will  expand  on  this 
trend  by  combining  processors  of  various  types  of  minimize 
problems  such  as  time-lag  between  control  input  and  system 
response,  and  to  provide  a  better  match  of  processor  power 
versus  individual  system  computing  tasks. 

An  example  of  this  is  the  NASA  Orbiter  Aero-Flight  Simulator 
system,  which  employs  one  medium  size  computer  for  basic  compu¬ 
tation,  background,  and  off-line  batch  processing;  and  separate 
mini  computers  to  handle  motion  system,  visual  system,  real¬ 
time  input/output,  and  space  shuttle  onboard  computer  inter¬ 
faces.  Such  a  system  could  be  expanded  further  to  include  mi¬ 
cro-processors  for  additional  special  applications  such  as 
linear  function  interpolation  (LFI) ,  fixed/float  conversions, 
or  other  data  formatting  tasks,  or  to  handle  special  peripheral 
devices . 

This  approach  provides  major  benefits  of  greater  computing  power 
and  flexibility  at  lower  overall  cost  than  can  be  obtained  with 
a  single  large  computer.  This  approach  is  especially  true  in 
the  light  of  the  recent  introduction  of  powerful  and  relatively 
inexpensive  micro-programmable  32-bit  minicomputers  and  other 
inexpensive  micro-programmable  devices  which  may  be  used  as 
building  blocks  in  a  large  real-time  computation  system  as  re¬ 
quired  for  the  FCIS. 

11.2.1  Computation  System  Accuracy  and  Resolution.  Most 
mini-computers  are  designed  for  16-bit  data  and  hence  use 
16-bit  instruction  word  lengths.  However,  16-bit  archi¬ 
tecture  has  limitations  if  large  programs  are  required,  or  if 
large  arrays  of  data  require  manipulation,  as  in  scientific, 
engineering,  simulation,  or  business  data  processing.  The  pre¬ 
sent  estimates  of  FCIS-LM  computer  instructions  plus  data  in¬ 
dicate  that  approximately  435K  bytes  of  memory  are  required  for 
resident  real-time  software  (not  including  spare) .  This  exceeds 
the  capacity  of  most  16-bit  computers.  Hence,  if  16-bit  com¬ 
puters  were  to  be  used  on  the  FCIS-LI1,  special  addressing 
and  data  file  techniques  organization  would  be  required.  The 
use  of  a  24-bit  or  32-bit  computer  frees  the  FCIS-LM  from 
this  limitation.  The  task  of  breaking  up  large  programs  to 
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fit  a  small  computer  is  eliminated.  A  32-bit  computer  also 
has  other  advantages  not  found  in  a  16-bit  machine,  inclu¬ 
ding  the  opportunity  to  increase  compiler  efficiency  through 
the  higher  speed  of  a  single-precision,  32-bit  and  double-pre¬ 
cision,  64-bit  floating-point  processing. 

These  attributes,  and  the  tradeoff  cost  comparisons  between 
16-bit  and  32-bit  computers  of  similar  speed,  have  led  to  the 
recommendation  to  use  a  32 -bit  computer. 

11.2.2  Computation  Software.  The  software  for  a  simulator  in 
a  multi-processor  configuration  is  typically  divided  among  each 
processor  according  to  the  tasks  to  be  performed.  The  parti¬ 
tioning  process  is  usually  accomplished  using  module  size  and 
instruction  timing  estimates  as  guides.  This  procedure  is  some 
times  supplemented  by  conducting  bench-mark  tests  on  the  equip¬ 
ment  to  determine  actual  performance  characteristics,  spare 
time,  and  core.  Typically,  the  design  of  a  simulator  computer 
system  is  an  iterative  process.  Certain  portions  of  the  hard¬ 
ware  and  software  are  designed  independently,  but  the  remaining 
portions  must  be  considered  interactively.  Currently,  there 
are  two  methods  of  partitioning  software  on  a  multi-processor 
system.  If  the  hardware  configuration  is  designed  first,  it 
will  dictate,  to  a  large  degree,  the  allocation  of  real-time 
software  tasks.  Alternately,  an  optimum  software  partitioning 
scheme  might  be  devised  first  and  the  hardware  designed  and  con 
figured  around  it.  However,  in  order  to  take  maximum  advantage 
of  the  benefits  of  a  multi-processor  configuration,  the  soft¬ 
ware  partitioning  required  is  the  total  computation  job  di¬ 
vided  into  separate,  independent  tasks.  Since  some  functions 
are  time-dependent  on  other  functions,  they  must  be  handled  in 
series,  rather  than  in  parallel  processors. 

However,  the  majority  of  functions  within  a  simulator  can  be 
partitioned  effectively  in  a  multiprocessor  system  where  pro¬ 
grams  can  execute  in  a  series-parallel  manner  without  negative 
effects  due  to  temporal  relationships. 

11.2.2.1  Software  Design  Methodology.  For  more  than  a  decade, 
simulation  software  design  methodology  has  evolved  from  the 
brute  force-machine  language  approaches  of  the  early  sixties, 
to  the  use  of  available  present-day  methodologies  including 
forms  such  as: 

o  Structured  Design 

o  Logical  Construction  of  Programs 

o  Higher  Order  Software 

o  The  Jackson  Methodology 

o  Meta  Step  Wise  Refinement. 


These  new  design  approaches  and  programming  concepts  have  been 
paralleled  by  the  development  of  programming  languages  includ¬ 
ing  assemblers,  meta-assemblers  and  support  software,  and 
higher  order  languages  such  as  APL,  BASIC,  PL/1,  FORTRAN,  COBOL, 
RPG,  and  others. 

11.2.2.2  Higher  Order  Languages.  The  desirability  of  using 
higher-order  languages  (HOL's)  for  real-time  simulation  is 
well  accepted  now  that  their  use  is  justified  by  the  price  and 
performance  of  computer  hardware.  Desirable  features  of  HOL's 
include  ease  of  training,  ease  of  programming,  faster  genera¬ 
tion  of  code  (lower  development  cost) ,  standardization  of  user 
software,  self-documenting  code,  and  fewer  development  errors. 

In  the  past,  problems  associated  with  using  existing  HOL's  for 
simulation  have  included  compiler  inefficiencies,  lack  of  large 
datapOol  support,  lack  of  features  such  as  bit  and  character 
manipulation,  and  lack  of  debugging  and  maintenance  aids. 

Recent  computer  hardware  advancements  —  e.g.,  faster,  low-cost 
memories  and  processors;  large,  inexpensive  disks;  fast,  float¬ 
ing-point  processors;  and  parallel  processing  —  have  opened 
many  new  doors  in  the  area  of  real-time  simulation.  These  doors 
include  the  ability  to  use  higher  order  language  and  multitask 
operating  systems  in  real-time.  However,  required  software 
tools,  including  compilers,  are  only  now  coming  of  age.  Due  to 
the  lag  in  the  development  of  support  software,  a  number  of 
problems  arise  when  using  existing  HOL's  in  simulator  systems. 
These  problems  fall  in  the  areas  of:  documentation  for  main¬ 
tainability,  datapool  support,  movement  of  code  by  optimizers, 
module  reliability,  fault  isolation,  bit  manipulation,  software 
change  turnaround  time,  subroutine  time  and  memory  overhead, 
configuration/change  control,  portability  between  computers, 
and  common  character  representation/manipulation.  These  prob¬ 
lems  require  that  the  user  have  a  knowledge  of  both  the  HOL 
and  assembler  language  for  each  computer  manufacturer.  All  of 
these  problems  can  be  (and  have  been)  overcome. 


Ideally,  a  well-defined  higher  order  language  (HOL) ,  specifi¬ 
cally  designed  for  real-time  simulation,  is  required.  This  lan¬ 
guage  should  be  specified  in  terms  of  the  simulation  environ¬ 
ment,  with  features  included  to  satisfy  the  various  design  and 
programming  tasks  which  arise  in  the  development  and  maintenance 
of  simulation  software.  The  major  goal  for  any  higher  order 
language  considered  for  a  real-time  simulation  environment  is 
the  efficient  use  of  both  human  and  hardware  resources.  Read¬ 
ability  and  writeability  of  the  language  constructs  should  min¬ 
imize  development  and  maintenance  time.  The  language  must  have 
external  options  in  the  compiler,  to  make  it  possible  to  take 
advantage  of  hardware  features  such  as  parallel  processors  and 
firmware  (floating  point,  trignometric  features,  and  function 
interpretation),  without  modifying  the  user's  source  code. 
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Even  though  HOL's  have  many  advantages  over  assembly  language, 
they  give  rise  to  problems  in  the  areas  of: 

o  Increased  memory  and  time  usage 

o  Compiler  reliability 

o  Module  interfaces  inefficiencies 

o  Large  datapool  support 

o  Debugging  and  verifying 

o  I/O 

o  Character  and  bit  manipulation 

o  Function/subroutine  efficiency. 

Also,  there  are  certain  types  of  simulation  programs  which  pose 
problems  in  specifying  a  HOL.  These  programs  include  the  exe¬ 
cutive,  I/O  handlers,  schedulers,  debugging  aids,  and  display  pro¬ 
cessors.  Each  of  these  and  other  types  of  programs  must  be 
analyzed  in  detail,  and  tradeoffs  must  be  made  as  necessary  in 
specifying  the  features  required  to  handle  the  problems  defined. 
Certain  processes  may  not  be  practical  to  include  in  the  simu¬ 
lation  higher  order  languages  (SHOL)  because  of  cost  and  imple¬ 
mentation  factors. 

11.2.3  Computer  Resource  Requirements.  The  analysis  of  FCIS-LM 
computer  resource  requirements  included  a  determination  of  all 
real-time^  on-line  and  off-line  software  and  associated  computer 
and  peripheral  equipments  required  to  support  the  armor  crew 
training  tasks.  Also  considered  were  those  additional  computa¬ 
tional  elements  required  of  a  laboratory-type  device  where  ad¬ 
ditional  training  programs  and  program  modifications  will  be 
developed  by  the  user  during  the  life  of  the  simulator. 

These  computational  systems  requirements  have  evolved  during 
the  course  of  the  study  where  tradeoffs  were  made  in  several 
system  areas  (i.e.,  visual,  crew  station,  vehicle  systems,  motion 
systems,  instructor  station)  relative  to  the  hardware  and  soft¬ 
ware  required  to  provide  each  specific  simulator  function. 

During  these  system  optimization  procedures,  individual  subsys¬ 
tem  real-time  program  module  accuracy,  computational  speed,  and 
instruction  and  data  requirements  also  were  determined. 

The  overall  computation  system  requirement,  including  special 
processing  requirements  such  as  visual  image  generation,  spec¬ 
ial  micro-processor  requirements ,  and  analog  or  hybrid  computers 
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has  been  studied.  To  date,  the  analysis  has  determined  that  no 
special  high-precision  analog  or  hybrid  computational  elements 
are  required  for  the  FCIS-LM. 

In  order  to  properly  evaluate  various  candidate  computer  sys¬ 
tems,  a  selection  model  was  prepared.  This  model  provides  one 
set  of  criteria  common  to  the  evaluation  process  for  each  can¬ 
didate.  The  elements  within  this  model  are  identified  in  Table 
11-5. 

Candidate  computer  systems  were  established  by  using  available 
computer  manufacturer  data. 

TABLE  11-5  DIGITAL  COMPUTATIONAL  SYSTEM  EVALUATION  CRITERIA 
o  Computational  speed 
o  Accuracy 
o  Reliability 
o  Maintainability 
o  Operability 
o  Simplicity  of  Design 
o  Cost 

o  Compiler  Efficiency 
o  Operating  System 

o  Support  Software 

■  I  ■  —— — — —  .1  —  !■■■  ■■  I  — . —■■■■■■ 

The  tradeoff  analysis  for  the  FCIS-  LM  digital  computer  system 
considered  the  following  computers : 

o  Amdahl  470/V6 

o  Univac  1100/43 

o  Interdata  8/32 

o  SEL  32/75,  32/55 

o  Digital  Equipment  Corporation  (DEC)  VAX  11/780 
o  IBM  370/168-1. 


During  the  study.  Link  has  determined  that  the  FCIS-LM  requires 
a  system  capable  of  executing  the  equivalent  of  at  least  £.3 
seconds  for  the  foreground,  plus  foreground  spare  and  operating 
system  overhead.  Table  11-6  provides  a  breakdown  by  system, 
detailing  the  requirement.  Additional  off-line  and  background 
program  requirements  are  shown  in  Table  11-7.  Disc  loading 
requirements  are  summarized  in  Table  11-8. 

11.2.3.1  Computation  Speed.  Link's  approach  in  evaluating 
CPU  computation  speed  was  to  take  a  simulation  benchmark  pro¬ 
gram  and  execute  this  on  each  computer  system  under  evaluation. 
During  the  summer  of  1977,  the  benchmark  was  successfully 
evaluated  on  the  following  systems : 

o  Amdahl  470/V6  -  Texas  A  &  M  University 

o  IBM  370/168-1  -  Gaithersburg,  Maryland 

o  Univac  1100  -  Houston,  Texas. 

The  MIPS  ratings  determined  for  each  system  are  shown  below: 

1)  Amdahl  470/V6  -  2.8  MIPS 

2)  IBM  370/168-1  -  3.6  MIPS 

3)  Univac  1100/42  -  1.6  MIPS/CAU  (0.38  MOP's  +  0.369  MOP's). 

All  computers  evaluated  either  meet  or  exceed  the  FCIS-LM  com¬ 
putational  speed  requirements.  At  the  time  that  these  mini¬ 
computer  systems  ware  evaluated,  the  Interdata  8/32,  SEL  32/75, 
and  the  DEC  VAX  11/780  minicomputer  systems  could  not  be  eval¬ 
uated  completely.  However,  subsequent  evaluations  were  made 
of  these  latter  three  systems  using  both  simulation  mix  and 
benchmark  runs  have  shown  that  these  systems  also  meet  the 
FCIS-LM  requirements.  Evaluation  results  indicate  that  the 
Amdahl  470/V6,  Univac  1100/43,  and  IBM  370  series  computers 
are  not  cost  effective  in  meeting  the  FCIS-LM  requirements. 

Thus,  the  selection  process  leaves  only  the  Interdata  8/32, 

SEL  32/75,  and  the  DEC  VAX  11/780  systems. 

Two  of  these  machines,  the  SEL  System  32/55  and  the  Interdata 
8/32,  are  now  in  use  on  simulators  which  have  been  delivered 
by  Link.  Each  of  the  three  manufacturers  have  proven  re¬ 
sponsive  to  the  needs  of  the  real-time  processing  market  and 
has  rendered  excellent  support  to  Link.  It  is  expected  that 
all  three  manufacturers  will  continue,  in  the  foreseeable 
future,  to  be  among  the  leading  suppliers  of  machines  of  this 
type. 

The  Digital  Equipment  Corporation  VAX  11/780  has  just  been  an¬ 
nounced  by  DEC  and  is  scheduled  to  be  available  in  the  third 
quarter  of  1978. 
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TABLE  11-6  FCIS-LM  COMPUTER  REAL-TIME  MEMORY  REQUIREMENTS 
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11.2.4  Computer  Peripheral  Requirements.  Peripheral  equipment 
is  required  to  support  the  digital  computer  system  in  both 
real-time  training  modes  and  background  batch  processing  and 
data  processing  activities. 

For  real-time  simulation  program  support,  a  disk  controller 
and  drive  are  required.  This  disk  system  provides  basic  re¬ 
quirements  for  on-line  mass  storage  of  all  real-time  simulation 
programs  and  data,  and  also  stores  all  of  the  off-line  utility 
and  diagnostic  programs.  A  back-up  disk  drive  is  recommended 
so  that,  in  the  event  of  the  primary  disk  failure,  it  shall  be 
possible  to  continue  training  operations  with  a  minimum  of  in¬ 
terruption.  A  computer  terminal  with  a  hard  copy  output  de¬ 
vice  also  is  recommended.  This  terminal  will  function  at  the 
primary  console  for  control  of  the  computer  operating  system. 
Support  peripherals  are  recommended  to  allow  software  support 
functions.  These  include,  as  a  minimum: 

o  A  400  cpm  card  reader  and  interface  controller 

o  A  600  1pm  line  printer  and  controller 

o  An  IBM  029  interpreting  keypunch 

o  A  dual  9-track  magnetic  tape  unit  and  controller. 

11.2.5  Computer  Program  Requirements 

11.2.5.1  Software  Design  Approaches.  Of  the  software  design 
methodologies  mentioned  previously,  structured  design  is  the 
most  familiar  in  the  simulation  world.  The  Jackson  Methodology 
and  LCP  are  primarily  business  oriented.  The  MSR  implies  an 
iterative  process  of  program  development  that  requires  an  ex¬ 
act  fixed  problem  definition.  It  works  most  effectively  in 
a  solution  involving  only  a  single  module  where  an  elegant 
solution  is  desired  (e.g.,  the  executive  program  for  an 
operating  system)  .  It  produces  a  level-structured,  tree-, 
structured  program.  Higher  Order  Software,  in  this  context, 
is  a  new  programming  language  being  used  on  the  NASA  Space 
Shuttle  program.  Compiler  and  support  software  are  not 
available  for  most  of  the  commercially  available  computers 
considered  for  the  FCIS-LM.  For  the  FCIS-LM  a  Structured 
Software  Design  methodology,  which  includes  top-down  pro¬ 
gramming  concepts,  is  recommended.  This  methodology  consists 
of  concepts,  measures,  analysis  techniques,  guidelines,  rules 
of  thumb  notation,  and  terminology. 

Reliance  is  placed  upon  following  the  flow  of  data  through  the 
system  to  formulate  program  design.  The  interpretation  of  the 
system  specification  is  used  to  produce  a  data  flow  diagram 
and  structure  chart.  The  design  process  usually  is  iterative. 
Identifying  incoming  and  outgoing  data  flow  boundaries  are 
used  to  define  modules  and  their  relation  ships;  however,  the 
boundaries  of  the  modules  can  be  redefined  almost  arbitrarily. 
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The  methodology  works  best  where  input  data  can  be  transformed 
into  outputs  in  incremental,  easy  to  follow  steps. 

This  method,  therefore,  is  well  suited  to  design  problems  such 
as  the  FCIS-LM,  where  a  well  defined  data  flow  can  be  derived 
from  the  problem  specifications.  Input  and  output  data  are, 
or  can  be  made,  well  distinguished  from  each  other,  and  data 
transformations  are  done  in  incremental  steps. 

11.2.5.2  Programming  Language.  For  the  FCIS-LM,  programming 
languages,  including  Assembler,  FORTRAN,  PL/1,  APL*,  and  BASIC, 
have  been  evaluated  against  the  present  and  long-term  require¬ 
ments  of  the  program.  These  languages  have  been  compared 
using  the  following  criteria: 

o  Program  efficiency 

o  Programmer  acceptability/training  requirements 
o  Computer  efficiency 

o  Transportability  between  different  computers 
o  Maintenance  and  documentation  features 
o  Ability  to  meet  future  requirements 

o  Life  cycle  cost. 

None  of  the  computer  manufacturers  considered  as  finalists  for 
the  FCIS-LM  provide  APL  or  PL/1  compilers  or  support  software. 
BASIC  is  severely  restricted  by  the  limitations  on  naming  of 
data,  data  base  structures,  program  size,  and  compiler  ef¬ 
ficiency. 

The  only  HOL  which  successfully  meets  all  of  the  criteria  is 
FORTRAN..  This  language  has  been  used  successfully  on  large 
scale  simulators  such  as  the  NASA  Skylab  and  Space  Shuttle, 
the  Air  Force  SAAC  and  ASUPT,  and  the  Navy  F-14  and  AWAVS. 
Therefore,  it  is  recommended  for  use  on  the  FCIS-LM. 

It  also  should  be  noted  that  DOD  Instruction  5000.31  allows 
only  FORTRAN  as  an  interim  HOL. 

11.2.5.3  Real-Time  Programs.  Real-time  computer  programs 
include  those  categorized  as  executive  programs,  synchronous 
application  programs  (which  simulate  the  vehicle  dynamics 
and  M60  subsystems),  motion  systems  programs,  and  those 
classified  as  advanced  training  programs. 

11.2.5.3.1  Executive  Programs.  The  following  programs  con¬ 
sidered  in  the  executive  class  are  required: 
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Supervisor  Real-Time  Executive  -  An  executive  program  is  re- 
qulred  in  each  simulator  computer  to  provide  simulator  synchro¬ 
nization  and  control  processing  in  consonance  with  the  resident 
real-time  operating  system.  Functions  coordinated  by  the  real' 
time  executive  should  include  disk  access  methods,  overlay  load¬ 
ing,  master-slave  CPU  synchronization,  and  operator  communica¬ 
tions  . 

Input/Output  -  Real-time  input/output  programs  are  required  to 
control  data  traffic  to  and  from  various  devices  such  as  signal 
conversion  equipment,  the  printer  plotter,  CRT  displays,  visual 
equipment,  and  remote  computer  control  units  and  digital  read¬ 
out  units  (DRU's). 

Closed-Loop  Linkage  Test  -  Programs  to  operate  in  simulator 
background"  time  are  required  to  test  and  monitor  the  status  of 
the  signal  conversion  equipment  _(SCE) .  These  programs  should 
monitor  output  channels  and  test  input  channels  in  the  spare 
I/O  time  available  between  real-time  system  I/O  updates.  Out¬ 
put  of  error  messages  should  be  sent  to  the  CRT/terminal  and  a 
hand  copy  device. 

Subroutines  Library  -  A  library  of  mathematical  procedures  is 
required  which  includes  a  numerical  integration  routine,  and 
standard  procedures  such  as  limits,  linear  function  interpola¬ 
tion  and  trigonometric  functions. 

11.2.5.3.2  Synchronous  Application  Programs  -  A  summary  of 
all  real-time  programs  along  with  the  iteration  rates  are 
given  in  Table  11-6. 

11.2.5.3.3  Motion  System  Programs.  The  motion  system  pro¬ 
vides  the  physical  cues  resulting  from  vehicle  maneuvers.  The 
vehicle  dynamics  software  provides  the  inputs  to  the  motion 
system  software  which  consists  of: 

o  Primary  motion  cue  generation  software 

o  Geometric  transformation  software 

o  Special  effects  software. 


11.2.5.3.4  Advanced  Training  Programs.  Advanced  Training  soft¬ 
ware  has  four  basic  categories: 
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STATUS  -  These  routines  present  the  status  of  the  simu¬ 
lator  to  the  instructor  and  the  experimenter.  Status/ 
control  pages  and  the  Vehicle  Position  Chart  are  pre¬ 
sented  on  the  IES  displays,  and  the  hardcopy  routines 
provide  a  permanent  record  of  these  pages  when  required. 

CONTROL  -  Control  of  the  simulator  is  provided  by  these 
routines ,  which  include  malfunctions,  initial  conditions, 
dynamic  replay,  the  exercise  monitor,  and  general  controls 
such  as  those  implemented  by  editing  the  status/control 
pages.  Also  included  as  control  routines  are  the  key¬ 
board  handlers  and  interpreters ,  as  the  function  key¬ 
board  gives  the  instructor  control  of  routines  in  all 
categories,  and  the  alphanumeric  keyboard  gives  the 
experimenter  his  own  additional  control  capability. 

EVALUATION  -  Trainee  proficiency  is  evaluated  through 
the  use  of  such  routines  as  Performance  Measurement, 
Exercise  Monitor,  and  Data  Analysis.  These  routines 
cam  all  be  modified  by  the  support  routines,  as  re¬ 
quired  to  suit  new  missions,  various  trainee  proficien¬ 
cy  levels,  experimentation  requirements,  etc. 

SUPPORT  -  These  routines  support  the  routines  in  the 
other  categories .  Three  are  off-line  routines:  Map 
(Vehicle  Position  Chart)  Generation,  Page  Generation, 
and  Exercise  &  Analysis  Formulation.  The  one  on-line 
routine  is  Parameter  Recording,  which  is  used  primarily 
by  the  experimenter. 

Both  the  instructor  and  experimenter  use  all  of  these 
routines,  with  the  experimenter  using  the  support  rou¬ 
tines  to  control  his  experimentation.  Some  routines 
fit  into  more  than  one  category,  such  as  the  status/ 
control  pages  and  the  exercise  monitor.  In  the  same 
manner,  many  basic  routines,  with  their  capabilities 
modified  by  the  support  routines,  provide  powerful 
experimentation  tools. 


11.2.5.4  Off-Line  Programs.  Off-line  programs  include: 
o  Simulation  Support  Programs 

o  Computer  System  Support  Programs 

o  Maintenance  and  Test  Programs 

o  Calibration  Test  Programs 

o  Utility  Support  Programs. 

Simulator  support  programs  are  required  to  verify  cycle  time, 
perform  ore-mission  checks,  and  to  provide  mission  support  for 
alphanumeric/ graphic  CRT  display  generation.  Computer  system 
support  programs  are  required  to  support  the  operating  system, 
control  peripheral  equipments,  support  software  development, 
loading,  and  test.  Memory  dump,  copy  and  trace,  and  special 
mathematical  library  software  are  included  in  this  category: 

Maintenance  and  test  programs  are  required  to  test  fully  the 
crew  station  system,  associated  interface  equipment,  signal 
conversion  equipment,  and  computer  peripherals.  Calibration 
test  programs  are  required  to  check  the  accuracy  and  flow  of 
all  signals  between  the  computer  and  all  external  simulator 
signal  sources  and  terminations. 

Utility  support  programs,  including  an  assembler,  compiler, 
trace  routines,  simulator  verification  routines,  data  base 
support  programs,  simulation  system  update,  and  modification 
control  routines  are  required. 

11.2.6  Computer  Selection.  The  FCIS-LM  computer  choice  has 
impact  over  a  considerable  period  of  time  if  follow-on  simula¬ 
tors  for  in-field  training  are  considered.  Procurements  could 
occur  over  a  period  of  several  years  or  longer.  It  is  re¬ 
cognized  that  this  kind  of  longevity  is  of  great  concern  to 
the  FCIS-LM  user.  Therefore,  every  effort  must  be  made  to  se¬ 
lect  a  computer  system  which  will  not  become  obsolete  during 
the  life  of  the  program.  As  mentioned  previously,  a  large 
number  of  computer  models  were  considered,  based  upon  the  re¬ 
quirements  which  have  evolved  for  the  FCIS-LM.  The  three 
candidates  which  were  shown  to  be  most  cost  effective  are  the: 

Interdata  8/32 

SEL  System  32 

DEC  VAX  11/780. 

Two  of  these  machines,  the  SEL  System  32  and  the  Interdata  8/32, 
are  now  in  use  on  simulators  which  have  been  delivered  by  Link. 
The  Digital  Equipment  Corporation  VAX  11/780  has  been  announced 
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by  DEC  and  is  scheduled  to  be  available  in  the  third  quarter  of 
1978.  Each  of  the  three  manufacturers  has  proven  responsive  to 
the  needs  of  the  real-time  processing  market  and  has  rendered 
excellent  support  to  Link.  It  is  expected  that  all  three  manu¬ 
facturers  will  continue,  in  the  foreseeable  future,  to  be  among 
the  leading  suppliers  of  machines  suitable  for  real-time  train¬ 
ing  simulation  applications. 

Of  these  three.  Interdata  and  SEL  were  selected  as  the  finalists 
for  this  study.  The  primary  reasons  for  eliminating  the  DEC 
VAX  11/780  at  this  time  are  (a)  the  lack  of  availability  of  a 
multi-port  memory,  (b)  the  requirement  for  extensive  develop¬ 
ment  of  new  real-time  executive  and  support  software,  and  Cc) 
higher  hardware  costs. 

11.2.6.1  Software  Feature  Comparison.  The  features  of  oper¬ 
ating  system,  support  software,  and  FORTRAN  were  compared  for 
both  Interdata  and  SEL.  The  SEL  RTM  has  been  in  use  since  1969 
while  the  Interdata  OS/32MT  has  been  in  use  since  1975.  Both 
operating  systems  have  been  used  in  building  simulation  systems; 
both  systems  have  adapted  well  to  the  areas  of  program  develop¬ 
ment  and  real-time;  both  systems  have  been  accepted  by  the 
government;  therefore,  both  systems  are  judged  to  be  equivalent. 
Similarly,  the  SEL  FORTRAN  has  been  in  use  since  1969  while  the 
Interdata  FORTRAN  has  been  in  use  since  1977.  Nonetheless, 
both  compilers  have  been  used  extensively  without  difficulty 
and,  thereby,  are  deemed  equivalent. 

A  table  of  features  for  the  software  area  is  prepared  below: 


OPERATING  SYSTEM 


INTERDATA 


Real  Time  Features 
Multi-tasking 
Overlay  Capability 
File  Structure 
Resource  Management 
Multi-terminal 
Foreground/Background 

SUPPORT  SOFTWARE 

Copy 

Trace 

Editors 

Debug 

Math  Library 
Microcode  Math  Library 
Loaders 
Assemblers 
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FORTRAN 


INTERDATA 


SEL 


AN Si  3.9  Standard 
ISA  Extensions 
Optimizations 
In  Line  Code 

Conditional  Compilations 
Run  Time  Debug 
OS  Integrated 


X 

X 

X 

X 

X 

X 

X 


X 

X 

X 

X 

X 


X 


11.2.6.2  Hardware  Feature  Comparison.  The  hardware  features 
of  the  INTERDATA  8/32,  the  SEL  32/55  and  the  SEL  32/75  are 
tabulated  below.  The  features  listed  are  all  relevant  to 
simulator  system  architecture. 


CENTRAL  PROCESSOR 


Interdata  SEL 

8/32  32/55 


SEL 

32/75 


Priority  Interupts  X 

Multiple  Register  Sets  X 

Concurrent  I/O  X 

Independent  I/O  X 

Large  Memory  Direct  Addressing  X 
High  Speed  DMA  X 

Precision  Timer  X 

Wide  Instruction  Set  X 

Bootstrap  X 

Indirect  Addressing 
Indexing  X 

OPTIONS 

Writable  Control  Store  X 

High  Speed  Floating  Point  X 

Multiport  Shared  Memory  X 

Microprogrammed  I/O  Device 

PERIPHERALS 

Large  Moving  Head  Discs  X 

High  Speed  Magnetic  Tapes  X 


X  X 


x 

X 

X 

x 

X 

X 

X 

X 

X 


X 

V 

/V 

X 

X 

X 

X 

X 

X 

X 


X 

X 

X  X 

X  X 


X  X 

X  X 


With  the  exception  of  the  multiple  register  sets,  the  CPU's  are 
feature-comparable.  Multiple  register  sets  cam  be  used  to  re¬ 
duce  context  switch  time  if  required.  The  INTERDATA  8/32  and 
the  SEL  32/75  offer  the  same  options  as  illustrated  above.  All 
computers  offer  the  same  basic  peripherals.  The  SEL  32/75, 
in  light  of  the  need  for  the  options  listed  above,  is  clearly 
preferred  over  the  SEL  32/55  for  FCIS-LM.  The  INTERDATA  8/32 
system  with  the  above  options  has  been  in  U3e  for  almost  two 
years.  The  SEL  32/75  with  the  same  options  is  yet  to  be  made 
available  for  delivery.  It  must  be  concluded,  therefore,  that 
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the  INTERDATA  3/32  computer  offers  an  advantage  in  the  FCIS-LM 
system. 


11.2.6.3  System  Performance.  A  large  measure  of  any  computer 
selection  decision  is  the  extent  to  which  hardware  and  software 
combine  to  provide  overall  computer  system  performance.  The 
measurement  of  system  performance  is  accomplished  through  the 
execution  of  benchmarks,  architected  for  use  in  a  simulation 
environment. 

a.  Simulation  Mix.  The  first  benchmark  (Table  11-9) 
measures  CPU  speed  as  a  function  of  an  instruction 
set  derived  from  simulation  programs  developed  by 
Link.  This  mix  provides  a  relative  measure  of  each 
computer's  hardware  execution  speeds. 

Average  Instruction  Time 
INTERDATA  8/32  1.55  (  seconds) 

SEL  32/75  1.65 

b.  KOPBM .  The  second  benchmark  has  been  provided  by 
NASA  and  is  prepared  in  FORTRAN  and  tests  compiler 
efficiency  as  well  as  CPU  speed.  The  results  of 
that  benchmark  are  listed  below.  Although  the  re¬ 
sults  are  presented  in  MOPS  (millions  of  operations 
per  second) ,  which  are  difficult  to  translate  to 
MIPS,  they  do  present  a  relative  measure  of  system 
performance. 

INTERDATA  8/32  0.215  MOPS 

SEL  32/75  0.161  MOPS 

One  can  conclude  that,  since  the  Simulation  Mix  re¬ 
sults  are  very  close,  the  INTERDATA  8/32  FORTRAN  system 
was  able  to  optimize  highly  the  KOPBM  test  and  account 
for  the  large  relative  difference. 

c.  ACMS.  The  third  benchmark  was  provided  by  the  Navy 
in  the  ACMS  REP.  The  F101  test  is  mainly  arithmetic, 
the  L127N  is  a  test  of  non-indexed  logical  operations. 
The  L127I  is  an  indexed  version  of  the  L127N  test. 

It  is  difficult  to  place  weights  to  the  values  of  the 
three  tests  other  than  to  say  that  typical  simulator 
problems  are  usually  more  than  33%  arithmetic.  The 
table  below  lists  execution  time  in  microseconds. 

F101  L127N  L127I 

623  381  444 

762  393  407 


INTERDATA  8/32 
SEL  32/75 
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Floating-Point  Register  -  Register 

Multiply  X  Register  5.7  1.85  0.105  3.95  .2251 
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The  core  memory  object  code  requirements  virtually  were 
the  same  for  all  systems .  The  benchmarks  were  construct¬ 
ed  such  that  little,  if  any,  structural  optimization 
could  be  accomplished. 

d.  Conclusion.  In  actual  system  performance ,  benchmarks 
KOPBM,  and  ACMS ,  the  INTERDATA  8/32  out-performed  the 
SEL  32/75.  The  INTERDATA  8/32  system  thereby  offers 
an  advantage  in  overall  capability  at  costs  which  have 
been  computed  as  comparable.  Benchmark  results  have 
been  provided  as  an  attachment  to  this  study  manuscript. 

11.2.6.4  Final  Selection.  On  the  basis  of  the  aforementioned 
comparisons,  the  SEL  System  32  and  the  INTERDATA  8/32  have 
equivalent  software,  but  the  INTERDATA  8/32  system  provides  a 
hardware  advantage  and  a  systems  performance  advantage.  There¬ 
fore,  the  INTERDATA  8/32  system  is  selected  over  the  SEL  System 
32  for  the  FCIS-LM. 

The  previous  discussions  related  to  technical  issues  only. 
However,  it  should  be  pointed  out  that,  of  the  finalists  con¬ 
sidered  for  this  selection,  the  INTERDATA  8/32  is  the  only 
computer  system  currently  in  the  U.S.  Army  inventory.  The 
INTERDATA  8/32  currently  is  used  on  two  BLACKHAHK  programs,  the 
helicopter  program  and  the  digital  visual  system  program.  Both 
of  these  8/32  systems  are  configured  almost  identically  to 
that  recommended  for  the  FCIS-LM.  . Familiarity  and  current  use 
of  this  configuration  leads  to  a  minimum  risk  approach  to  the 
computer  area.  Computer  hardware  commonality  is  a  fallout 
from  the  selection  of  INTERDATA  8/32  for  FCIS-LM. 

The  recommended  FCIS-LM  computational  system  is  shown  in  Figure 
11-12.  A  three-CPU  Multiprocessor  system  is  required  to  sat¬ 
isfy  the  real-time  program  and  spare  requirements.  One  pro¬ 
cessor  is  configured  with  512K  bytes  of  750-nanosecond  core 
memory;  the  second  and  third  with  25 6K  bytes.  In  addition,  a 
128K  byte  shared  memory  is  incorporated. 

Each  of  the  central  processors  also  is  equipped  with  a  high¬ 
speed,  floating-point  arithmetic  unit  and  a  2048-word  writeable 
control  store  option.  The  basic  peripheral  units  include  an 
80-megabyte  moving-head  cartridge-disk  system,  a  backup  80- 
megabyte  disk  drive,  an  Interdata  Carousel  30  for  use  as  an 
operator  console,  and  a  CRT  Terminal  display  keyboard  and  hard 
copy  system.  The  writeable  control  stores  will  be  programmed 
with  the  FORTRAN  run  time  library  to  enhance  throughput. 

In  addition,  a  1000  cpm  card  reader,  a  600  1pm  line  printer  and 
an  interpreting  keypunch  are  provided  for  software  support 
operations.  The  1000-cpm  card  reader  is  recommended  to  achieve 
added  throughput  capability. 
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FIGURE  11-12  FCIS  COMPUTATIONAL  SYSTEM 


A  number  of  special  devices  are  also  required  as  interfaces  to 
the  computer  system.  These  special  interfaces  are  utilized  to 
perform  computer-related  functions  necessary  for  digital  and 
analog  communications,  display  processing,  and  instructor  con¬ 
trol. 


11.2.7  Performance 


11.2.7.1  Central  Processors.  Each  central  processing  unit 
should  be  an  Interdata  8/32  general-purpose  processor,  which 
is  a  high-performance,  32-bit,  fully  parallel  processor.  The 
CPU's  have  the  following  characteristics: 

°  Dual  64-bit  look-ahead  stacks 

o  Two  sets  of  16  general-purpose  registers  (each  32  bits 
wide) 

o  Direct  addressing  for  1,048,576  bytes  of  memory 

o  1024  interrupt  levels 

o  A  binary  display  panel 

o  Power  fail  detection  and  automatic  restart 

o  Privileged  instruction  detect 

o  Provision  for  up  to  1024  auto  driver  channels. 

11.2.7.1.1  Central  Processor  Options.  Each  central  processor 
requires  the  following  devices  to  be  directly  interfaced  to  it 
on  the  multiplexer  bus: 

a)  Loader  storage  unit,  with  special  32-bit  bootstrap  for 
disk  and  card  reader,  as  well  as  a  watchdog  timer. 

b)  Interrupt  module,  which  provides  8  input  interrupts 
and  2  output  interrupts. 

c)  Universal  clock  module  containing  a  precision  interval 
clock  which  provides  interrupts  to  the  CPU  with  a  resolu 
tion  of  either  1,  10,  or  100  microseconds. 

d)  Hexadecimal  display  panel  which  includes  an  advanced  hex 
adecimal  light-emitting  diode  (LED)  readout  and  hexadeci 
mal  input  keyboard.  It  also  provides  a  key-operated  on/ 
off /lockout  switch. 
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11.2.7.1.2  Processor  Enhancements 

a)  Writeable  Control  Store  -  A  writeable  control  store  (WCS) 
should  be  provided  in  each  CPU  to  improve  performance 
while  executing  highly  repetitious  calculations  such  as 
the  standard  library  subroutines.  The  following  charac¬ 
teristics  are  provided: 

o  Type  of  memory:  high-speed  bipolar 

o  Memory  access  time:  1.0  microseconds 

o  Size  of  memory:  2048  x  32-bit  words 

o  Added  instructions  to  8/32  instruction  set 

-  Write  Control  Store  (privileged) 

Read  Control  Store  (privileged) 

-  Enter  Control  Store 

-  Branch  to  Control  Store  (privileged) 

b)  High-Performance  Floating-Point  Arithmetic  Unit  -  A  high- 
performance  floating-point  arithmetic  unit  should  be  pro¬ 
vided  in  each  CPU  to  allow  efficient  execution  of  the 
FORTRAN-generated  arithmetic  statements.  The  floating¬ 
point  unit  provides  LOAD,  STORE,  and  COMPARE  instructions 
as  well  as  the  standard  floating-point  arithmetic  instruc¬ 
tions  of  ADD,  SUBTRACT,  MULTIPLY  and  DIVIDE.  The  operands 
may  be  either  single  (32-bit)  or  double  (64-bit)  precision 
quantities  and  separate  registers  are  utilized  for  the 
different  types  of  precision.  The  floating-point  unit 
also  has  additional  instructions  to  convert  from  fixed- 
point  to  floating-point  representation  and  vice  versa. 

The  complete  instruction  set  added  by  the  high-performance 
floating  point  unit  and  the  minimum  execution  times  for 
the  instructions  are  given  in  Table  11-10. 


|  11.2.7.2  Memory  Systems 

11.2.7.2.1  Private  Memory.  Each  central  processor  in  the  sys¬ 
tem  should  be  configured  with  sufficient  private  memory  to  per- 
(  form  the  real-time  computations  efficiently.  The  memory  system 

*  should  have  the  following  characteristics: 


o  Core  memory 
o  750-nanosecond  cycle  time 
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TABLE  11-10  INSTRUCTION  SET 


INSTRUCTION 

EXECUTION  TIME  (MICROSECONDS) 

Single- Precis  ion 

Double-Precision 

load  FLOATING  POINT 

1.39 

2.91/3.28 

LOAD  FLOATING  POINT  REGISTER 

1.04 

1.04 

LOAD  FLOATING  POINT  MULTIPLE 

3.57  +  1.34N 

3.69  +  2.19N 

STORE  FLOATING  POINT 

2.23/2.60 

2.75/2.81 

STORE  FLOATING  POINT  MULTIPLE 

3.59  +  0.90N 

4.50  +  1.80N 

ADD  FLOATING  POINT 

1.82 

3.38/3.75 

ADD  FLOATING  POINT  REGISTER 

1.00 

i.04 

SUBTRACT  FLOATING  POINT 

1.82 

3.38/3.75 

SUBTRACT  FLOATING  POINT  REGISTER 

1.00 

1.04 

MULTIPLY  FLOATING  POINT 

2.50 

4.90/5.30 

MULTIPLY  FLpATING  POINT .REGISTER 

1.75 

2.50 

DIVIDE  FLOATING  POINT 

4.45 

9.20/9.65 

DIVIDE  FLOATING  POINT  REGISTER 

3.60 

6.70 

COMPARE  FLOATING  POINT 

1.45 

3.00/3.40 

COMPARE  FLOATING  POINT  REGISTER 

0.60 

0.60 

FIX  REGISTER 

5.35 

8.10 

FLOAT  REGISTER 

2.00 

2.00 

NOTE:  THE  FOLLOWING  CONDITIONS  WILL  CAUSE  THE  EXECUTION  TIMES  TO  BE  INCREASED: 

0  NORMALIZE  RESULT  (ADD,  SUBTRACT,  MULTIPLY,  DIVIDE,  LOAD)  -  100  NANOSECONDS 
PER  HEXADECIMAL  DIGIT  SHIFTED. 

0  EQUALIZE  EXPONENTS  (ADD,  SUBTRACT)  -  100  NANOSECONDS  PER  HEXADECIMAL  DIGIT 
SHIFTED. 

0  ALTERNATE  l'S  AND  O'S  (MULTIPLY). 

0  POSITION  OF  INSTRUCTION  IN  LOOK-AHEAD  STACK  -  CAN  INCREASE  TIME  BY  400  NS 
MAX,  IF  IT  CAUSES  STACK  TO  REFILL. 
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o  Parity  error  detection 

o  Minimum  increment:  131,072  bytes 

o  Maximum  memory  size:  1,048,576  bytes 

o  Interleaving  method:  4-way 

11.2.7.2.2  Shared  Memory.  In  addition  to  the  private  memory 
defined  above,  each  CPU  will  be  directly  interfaced  to  a  shared 
memory  system.  The  memory  boards  utilized  in  the  shared  memory 
should  be  identical  to  the  private  memory  specified  above.  In 
addition,  the  shared  memory  system  should  have  the  following 
characteristics : 

o  Throughput  rate:  10  megabytes/second 

o  Maximum  number  of  ports:  16 

o  Interleaving  method:  Halfword  interleaved 

o  Propagation  delay  caused  by  multiplexing:  700  ns  (read) , 

0  ns  (write) 

11.2.7.3  Shared  Peripherals 

11.2.7.3.1  Bus  Switches.  Input/output  bus  switches  should  be 
provided  as  a  convenienc  and  inexpensive  means  of  enabling  mul¬ 
tiple  processor  access  to  a  common  I/O  bus.  The  bus  switches 
should  operate  in  the  following  manner: 

1)  The  common  I/O  bus  should  be  idle  unless  a  switch  has 
been  requested  and  has  been  granted  bus  control 

2)  If  the  bus  is  busy,  requests  for  access  from  other  switches 
should  be  registered  within  the  switch  for  response  as 
soon  as  the  bus  is  released. 

3)  A  master/slave  option  should  be  implemented  allowing  one 
designated  switch  in  the  multiple-processor  configuration 
to  assert  unqualified  control  over  the  shared  bus,  ter¬ 
minating  transfer  to/from  the  common  bus  by  slaves. 

4)  The  switches  should  be  solid-state  and  have  a  control 
panel  which  allows  a  manual  override  control  for  up  to 
six  processors  sharing  a  single  common  switch  bus. 


Two  setr  of  bus  switches  should  be  provided,  with  one  set  being 
dedicated  to  the  selector  channel  for  the  disk  and  the  second 
set  being  utilized  for  the  devices  interfaced  to  the  multi¬ 
plexer  bus,  as  defined  in  the  following  paragraphs. 

11.2.7.3.2  Shared  Selector  Channel  Peripherals 

a)  Disk  Drive  and  Controller  -  A  3330-type  disk  drive  and 
controller  subsystem  should  be  provided  to  meet  the  basic 
requirements  for  on-line  mass  data  storage.  The  control¬ 
ler  provided  should  have  the  capability  of  controlling 

up  to  four  disk  drives.  The  disk  drive  should  have  the 
following  characteristics: 

o  Transfer  rate:  1,200,000  bytes  per  second 
o  Bit  density:  nominal  6000  bits  per  inch 
o  Track  density:  384  tracks  per  inch 
o  Cylinders:  823 
o  Tracks  per  cylinder:  5 
o  Sectors  per  track:  64 
o  Bytes  per  sector:  256 
o  Formatted  capacity:  67,200,000  bytes 
o  Track-to-track  switching  time:  7  milliseconds 
o  Maximum  track  seek  time:  55  ms 
o  Average  access  time:  30  ms 
o  Maximum  rotational  latency:  16.67  ms 
o  Average  rotational  latency:  8.33  ms 
o  Write  protect  (selectable) 

b)  Backup  Disk  Drive  -  Another  disk  drive  should  be  inter¬ 
faced  into  the  controller  of  the  disk  so  that  in  the  event 
of  a  failure  of  the  primary  disk  it  shall  be  possible  to 
continue  training  with  a  minimum  of  interruption.  This 
drive  should  be  functionally  interchangeable  with  the  pri¬ 
mary  disk  drive. 
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c)  MTU  Controller  and  MTU's  -  Two  identical  magnetic 
tape  units  should  be  provided,  arranged  as  two 
1x4  controllers  and  one  primary  drive,  plus  one 
expansion  drive,  with  the  following  characteristics: 

o  800  and  1600  bits  per  inch 

o  75  inches  per  second  for  read  and  write 

o  200  inches  per  second  rewind 

o  Read  and  write  capability 

o  Parity  checking  with  corrective  action 

o  The  proposed  configuration  allows  two  units 

to  operate  concurrently 

o  10.5  inch  reels 

o  Recorded  tape  formats  are  IBM  standard  unlabeled 
ASCII  or  EBCDIC  formats  which  will  interchange 
with  the  CYBER  74  in  the  appropriate  I/O  modes, 
o  Binary  and  ANSI  II  character  recording  modes. 
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11.2.7.3.3  Shared  Multiplexer  Bus  Peripherals 

a)  Carousel  30  Computer  Terminal  -  Carousel  30  terminals 
should  be  provided  to  function  as  operator  consoles  to 
the  Interdata  operating  system  (OS-32MT) .  It  will  be 
interfaced  to  the  multiplexer  bus  via  a  current  loop  in¬ 
terface.  This  equipment  should  have  the  following  char¬ 
acteristics: 

Print  Speed:  30  characters  per  second 
Character  Set:  64  character  ASCII 
Print  Line:  80  characters 
Current  Loop  Interface:  20  mA 
External  Cable:  Provided 
50Hz  Operation:  Provided 
Acoustic  Cover:  Provided 
Pedestal  Cover:  Provided 

Basic  Supply  Kit:  6  ribbon  cartridges  and  3  print  cups 

b)  CRT  Terminal,  Keyboard ,  Hardcopy  Unit  - 

Terminal  and  Keyboard  -  The  CRT  terminal  and  keyboard  should  be 
an  Interdata  Model  1100  equivalent  and  should  meet  the  follow¬ 
ing  specifications: 

Number  of  Lines:  24 

Characters  Per  Line:  80 

Character  Generation:  9  x  12  dot  matrix 

Character  Code:  128  ASCII 

Refresh  Rate:  Line  Frequency  (50  or  60.Hz) 

Scan  Method :  Raster 

Phosphor:  p4  White 

Cursor:  Reverse  video  block 

Data  Entry:  Cursor-determined  or  bottom  line  scroll  upward 

Communication  Interface:  RS232C/CCITT-V24  or  20  mA  current 

loop 


Transmission  Mode:  Half  or  full  duplex  (switch  selectable) 

Baud  Rates:  75,  110,  200,  300,  600,  1200,  1800,  2400,  4800, 
7200,  9600,  (switch  selectable) 

Character  Format:  10  or  11  bits 

Parity:  Odd,  Even,  Mark,  Space  (switch  selectable) 

Stop  Bits:  One  or  Two  (switch  selectable) 

Printer  Interface:  RS232C  or  20  mA  current  loop  (optional) . 

Baud  rates  of  75,  110,  200,  300,  600, 
1200,  1800,  2400,  4800,  7200  and  9600 

Dimensions 

Height:  19.5  inches  (49.5  cm) 

Width:  21.5  inches  (54.6  cm) 

Depth:  23.5  inches  (59.7  cm) 

Weight:  50  pounds  (22.7  kg)  (shipping) 

Power:  115  VAC  +10%,  60  Hz 
230  VAC  +10%,  50  Hz 

Environment 

Temperature:  0  to  45°C  operating 

Humidity:  0  to  80%,  no  condensation 

Hardcopy  Unit  -  The  hardcopy  unit  should  be  a  Hazeltine  Thermal 
Printer  Unit  or  equivalent  meeting  the  following  specifications 

Print  Speeds:  10  -  30  cps 

Carriage  Width  (Cols.):  80 

Paper  Feed:  Friction 

Interface:  Operates  in  conjunction  with  commercially  avail¬ 
able  video  display  terminals 

Controls:  On-line,  line  feed,  carriage  return,  power  on/off 
Printable  Characters:  64  USASCII,  upper  case 
Paper  Size  and  Type:  8%" 

Ribbon :  None 


Spacing:  Horiz:  10  characters  per  inch; 

Vertical:  6  lines  per  inch 

Power:  Single  Phase,  120  VAC,  60  Hz;  2  amps 

Size:  6  in.  H;  16  in.  D.  W 

c)  Digital  Remote  Control  Units 

1)  Two  Termiflex  Corporation  HT/4  terminals  and  appropri¬ 
ate  software  should  be  provided.  These  terminals 

are  approximately  7  inches  high  x  4*s  inches  wide  and 
2  inches  in  depth  and  weigh  approximately  13  ounces. 
The  front  panel  layout  is  shown  in  Figure  11-13. 

2)  These  portable  units  should  connect  into  jacks  which 
will  be  located  in  the  crew  station  areas.  The  DRU 
shall  be  interfaced  to  the  computer  complex  via  stand¬ 
ard  RS232  interfaces  on  the  shared  multiplex  bus. 

3)  No  physical  modifications  of  the  devices  should  be 
necessary;  however,  different  key  nomenclature  should 
be  applied  to  the  function  keys,  located  on  the  bottom 
row. 

4)  The  expanded  keyboard  entry  capability  should  provide 
a  full  set  of  alphanumeric  key-ins  as  well  as  the 
special  control  keys,  thereby  providing  a  full  message 
capability  such  as  that  found  on  a  teletypewriter. 

5)  The  LED  display  readout  display  should  consist  of  two 
rows  of  12  characters  each  and  should  be  used  to  dis¬ 
play  either  the  physical  core  address  or  the  symbolic 
name  of  a  variable  as  well  as  its  numerical  value. 

DRU  Operational  Description 

1)  The  DRU  should  function  as  a  real-time  debug  program 
which  processes  inputs  from  the  function  switches  and 
keyboard  and  produces  the  displays  and  alarm  indications 
consistent  with  the  capabilities  described  in  (TBD) 
through  (TBD) . 

2)  The  program  should  validate  the  input  data  and  determine, 
by  scanning  the  list  of  input  characters,  the  function 
to  be  performed.  The  input  string  should  be  considered 
terminated  when  all  the  required  predetermined  data  has 
been  received.  A  continuous  update  of  the  data  displayed 
will  be  provided  upon  detection  of  the  "repeat"  function 
signal  having  been  received. 

3)  The  data  display  should  be  updated  and  the  display  re¬ 
freshed  at  the  rate  of  1200  baud. 
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4)  In  addition  to  the  value  displayed,  either  the  hexadeci¬ 
mal  machine  location  (address)  or  the  symbolic  name  of 
the  variable  taken  from  the  symbol  dictionary  should  ap¬ 
pear  in  the  LED  display. 

5)  The  real-time  executive  program  should  also  interface  with 
the  DRU  program  module  to  provide  the  capability  for  the 
display  of  cycle  and  frame  timing  information  as  well  as 
other  significant  messages  relating  to  the  status  of  the 
real-time  simulation  processing. 

Function  Switches  -  The  principal  function  switches  will  oper- 
ate  in  the  manner  described  below  in  any  mode: 

Switch  Name  Function 

ENT  (ENTER)  Initiates  loading  of  keyboard  data 

as  input  to  one  of  four  other  func¬ 
tions:  Mode,  Address,  Data  or 
Scale.  The  keyboard  data  is  loaded 
into  the  selected  function  register. 

Initiates  updating  of  the  display, 
and  upon  validation  initiates  stor¬ 
age  of  data  into  the  selected  mem¬ 
ory  address. 

FRZE  (FREEZE)  Freezes  the  simulation  problem  while 

allowing  the  DRU  to  alter  and  read 
out  the  contents  of  any  register/ 
memory . 

DIS  (DISPLAY)  Initiates  display  of  the  selected 

function. 

I/D  (INCREMENT/DECREMENT)  Increments  or  decrements  the  address 

prior  to  entering  or  displaying  data 
for  the  new  address. 

RPT  (REPEAT)  Provide  a  continuous  update  of  value 

displayed. 

The  remaining  five  function  switches  are  used  to  select  the 
function  register  into  which  the  keyboard  data  is  to  be  loaded, 
or  the  function  which  is  to  be  displayed. 
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The  significance  of  the  keyboard  is  described  below: 


Switch 


Data  Entry 


Function 


MODE  (MODE)  00 
01 
02 
03 
04 
10 
11 
12 
20 
21 


Not  used  (ignored) 

Register  Monitor 

Monitor  Data,  Hexadecimal  Format 
Monitor  Data,  Decimal  Format 
Monitor  Boolean  State 
Not  used  (ignored) 

CPU  1 
CPU  2 
Increment 
Decrement 


ADR  (ADDRESS)  1  digit  Register  Address  (Hexadecimal  Format) 
2  or  more  Memory  Address  (Hexadecimal  Format) 
digits 

3-6  charac-  Symbolic  name  of  variable 
ters 


DAT  (DATA) 


40 

41 

(8 

di- 

gits) 

42 

(8 

di- 

gits) 

43 

(8 

di- 

gits) 

44 

(8 

di- 

gits) 

Not  used 

Decimal  in  floating  point  stored  in 
memory 

Hexidecimal  data  to  be  stored  in 
memory 

Decimal  data  to  be  scaled  and  con¬ 
verted  to  hexidecimal  and  stored  in 
memory 

Floating  decimal  displayed 


SCALE  (SCALE) 


50-53  Not  used 

54 (+2  di-  Floating  decimal  used  to  scale  data 
gits)  to  be  stored  in  memory  or  to  rescale 

data  read  from  memory.  All  floating 
point  data  entered  is  normalized 
prior  to  storage  in  memory. 


CLR  (CLEAR) 


(Ignored)  Clears  display,  uncomputed  entries. 


Keyboard 


1)  Ten  digits  are  provided  in  the  keyboard  register.  Depres¬ 
sing  the  CLR  function  sets  the  keyboard  register  to  all 
zeros.  As  each  key  (except  the  decimal  point)  is  depres¬ 
sed,  the  corresponding  digit  (0  through  F)  is  loaded  into 
the  upper  least  significant  digit  (LSD)  of  the  display, 
shifting  the  contents  of  the  display  register  one  digit  to 
the  left  (the  digit  in  the  most  significant  digit  location 
being  shifted  out) .  In  the  decimal  mode  the  most  signifi¬ 
cant  digit  (MSD)  represents  the  sign. 
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2)  The  decimal  point  key  is  effective  only  when  entering  data 
or  scale  if  the  decimal  mode  has  been  selected.  In  this 
case  the  decimal  point  will  take  effect  at  the  location 
where  it  is  loaded. 

3)  When  data  has  been  entered  into  the  keyboard  register  to 
the  satisfaction  of  the  operator,  depressing  the  "ENTER" 
switch  will  load  the  contents  of  the  keyboard  register  into 
one  of  four  internal  function  registers  (Mode,  Address, 

Data  or  Scale) . 

Displays  -  The  displays  should  consist  of  two  10-character  LED 
readouts,  capable  of  displaying  the  full  set  of  128  ASCII  char¬ 
acters: 

1)  Numeric 


a)  The  upper  10-digit  readout  should  be  capable  of  dis¬ 
playing  the  data  in  hexadecimal,  octal,  and  decimal  for¬ 
mats.  The  largest  number  that  will  be  displayed  in  hex¬ 
adecimal  format  is  "FFFFFFFF".  In  address  mode  the  four 
digits  on  the  left  (MSD's)  shall  be  blanked  and  the  hex¬ 
adecimal  data  will  be  displayed  in  the  remaining  six 
digits  on  the  right. 

b)  The  largest  number  that  can  be  displayed  in  decimal  for¬ 

mat  is  "+99999999".  In  this  case,  all  ten  readouts  are 
active,  with  the  MSD  representing  a  "+”  or  a  The 

decimal  point  should  also  be  displayed  in  one  of  ten 
places,  after  the  sign,  between  digits,  or  after  the 
last  digit. 

2)  Alphabetic  -  Alphabetic  character  data  should  be  displayed 
m  the  lower  12-digit  LED  display.  The  messages  to  be  dis¬ 
played  include: 

FREEZE  -  When  the  freeze  function  has  been  entered. 

INVALID  -  Upon  detection  of  a  syntactical  input  error. 

TRUE  or  FALSE  -  Upon  the  display  of  a  boolean  vari¬ 
able  (Mode  04) . 

ABORT  -  Upon  detection  of  a  CPU  abort  situation  by  the 
executive  program. 

3)  Message  Bell  -  The  HT/4  should  produce  an  audible  beep 
when  any  of  the  following  conditions  occur: 

a)  Depressing  a  key  when  not  clear  to  send. 

b)  Attempting  to  generate  an  improper  character. 
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4)  Support  Peripherals  -  The  following  devices  should  be  pro¬ 
vided  with  the  FCIS  LM  to  allow  software  support  func¬ 
tions  : 

o  A  600  (min)-cpm  card  reader  and  interface  controller 
o  A  600-lpm  line  printer  and  controller 
o  An  IBM  Model  029C  interpreting  keypunch 
11.2.7.4  Special  Function  Interfaces. 

a)  Interdata  Universal  Logic  Interfaces  (ULI)  should  be  util¬ 
ized  to  provide  the  interface  between  the  computer  complex 
and  the  following  hardware: 

1)  Instructional  Display  System 

2)  Signal  Conversion  Equipment 

The  Interdata  ULI  contains  a  processor  interface  including 
address  selection,  interrupt  control,  and  data  buffer. 

The  interface  is  factory-designed  as  a  totally  functional 
16-bit  input/output  module  with  the  capability  to  output 
16  latched  lines,  four  control  lines,  and  an  initialize 
line.  In  addition,  16  independent  TTL-compatible  input 
lines  are  included  that  are  complemented  with  8  status 
lines  and  an  interrupt  line. 

The  interface  should  be  used  as  an  I/O  extension  of  the 
selector  channel  and  should  be  designed  to  transfer  data 
at  rates  up  to  1,900,000  bytes  per  second. 

The  custom  logic  design  portion  of  the  interface  allows 
for  up  to  77  integrated  circuits  using  either  14-  or  16-pin 
dual  in-line  IC's.  The  custom  logic  design  portion  for 
each  of  the  required  interfaces  will  be  incorporated  on 
the  ULI,  resulting  in  several  unique  ULI  designs  all  based 
on  the  same  system  module.  The  function  provided  by  the 
first  six  interfaces  are  explained  elsewhere  in  this  spec¬ 
ification.  The  SCE  is  described  in  paragraph  11.2.7.5. 


b)  Visual  System  Interface  -  The  visual  system  (DIG)  should 
be  interfaced  via  the  Interdata  8/32  shared  memory. 

Either  a  direct  interface  (multiprocessor)  or  a  processor/ 
processor  interface  (multicomputer)  is  acceptable  because 
of  the  very  low  data  interchange  requirement  (less  than 
25000  bytes  per  second) . 
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11.2.7.5  Signal  Conversion  Equipment  ~~ 

a)  A  Link-built  signal  conversion  equipment  (SCE)  system  can 
be  provided  to  interface  the  computer  complex  with  the 
FCIS-LM  crew  station  hardware.  It  shall  provide  for  dis¬ 
crete  inputs,  discrete  outputs,  analog  inputs,  and  analog 
outputs  to  and  from  the  computer  complex. 

b)  A  functional  block  diagram  of  the  interface  equipment  is 
shown  in  Figure  11-14.  The  interface  equipment  will  con¬ 
sist  of  a  computer  interface,  a  master  controller,  several 
subcontrollers,  and  the  required  number  of  interface  elec¬ 
tronic  cards. 

c)  The  interface  equipment  I/O  data  should  be  arranged  in  data 
pools  resident  in  the  shared  memory  system.  Once  every  33 
milliseconds,  the  host  computer  complex  will,  thus,  cause 
an  interchange  of  information  between  the  master  control¬ 
ler's  memory  system  and  the  host  computer's  memory  system. 

d)  The  DMA  interface  between  the  master  controller  and  the 
host  computer  memory  should  perform  the  necessary  conver¬ 
sions  between  the  formats  of  the  data  in  the  master  con¬ 
troller  and  the  data  in  the  memory  of  the  host  computer 
system,  according  to  Table  11-11. 

e)  In  the  cases  where  the  conversion  is  not  done  in  the  DMA 
interface,  software  routines  should  be  utilized  to  convert 
the  data  into  the  required  formats. 

Table  11-12  delineates  signal  conversion  equipment  requirements 
and  provisions  for  the  FCIS  Instructor  Station,  Fighting  Station, 
and  Driver  Station.  For  the  SCE  provided,  including  spare  in 
excess  of  25%,  and  with  all  I/O  occurring  at  a  30  Hertz  rate, 
a  total  data  transfer  of  260  Kbits  per  second  is  anticipated. 

This  is  well  within  the  nominal  SCE  transfer  rate  of  1  Megabit 
per  second. 


TABLE  11-11  DMA  DATA  FORMAT  CONVERSIONS 


Format  in 

Format 

in  Host 

Master  Controller 

Computer 

Converted 

Discrete  Inputs 

Single 

bit  in 

32-bit 

word 

No 

16-bit 

word 

Discrete  Outputs 

Single  bit  in 

32-bit 

word 

Yes 

16-bit 

word 

Analog  Inputs 

16-bit 

fixed- 

32-bit 

floating- 

No 

point  number 

point  number 

Analog  Outputs 

16-bit 

fixed- 

32-bit 

floating- 

Yes 

point  number 

point  number 

TABLE 
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SCE  REQUIREMENTS 

AI 

DI 

AO 

LO 

Requirement 

IES 

4 

47 

— 

25 

Fighting  Station 

10 

75 

20 

64 

Driver  Station 

9 

28 

35 

20 

SUBTOTAL 

2 3 

150 

55 

109 

SPARE 

6 

38 

14 

28 

TOTAL 

29 

186 

69 

137 

Provision 

IES 

7 

64 

8 

64 

Fighting  Station 

28 

256 

32 

192 

Driver  Station 

28 

64 

32 

128 

TOTAL 

63 

364 

72 

384 

I/O  Transfers 

per 

1890 

720* 

2160 

11520 

second 

*  16-bit  packed  words 
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Interface  System  Block  Diagram 


11.2.7.5.1  Master  Controller  Functions.  The  master  controller 
will  be  the  central  controller  for  the  signal  conversion  (inter¬ 
face)  equipment  system  and  should  provide: 

a)  Communication  with  the  computer  I/O  data  memory  via  the 
DMA  channel.  The  DMA  provides  word-serial,  bit-parallel, 
two-way  communication  with  the  computer  I/O  data  memory 
via  a  standard  interface. 

b)  Parallel-to-serial  data  conversion  for  the  output  data 
stream. 

c)  Serial- to-parallel  data  conversion  for  the  input  data 
stream. 

d)  Address  translation  from  computer  memory  I/O  data  address 
to  interface  electronics  and  address. 

e)  Synchronizing  clocks  for  the  subcontroller  and  interface 
electronics  cards. 

f)  Message  control  to  the  subcontroller  and  interface  elec¬ 
tronics  cards. 

g)  Control  for  achieving  the  closed-loop  interface  equipment 
test. 


11.2.7.5.2  Subcontroller  Card  Functions 

a)  The  subcontrollers  should  provide  the  capability  for  reli¬ 
able  serial  data  communication  between  the  master  control¬ 
ler  and  the  interface  electronics  cards.  A  bit-serial 
data  transmission  stream  will  be  utilized  for  transmitting 
output  information  (analog  outputs,  discrete  outputs)  from 
the  master  controller  to  the  interface  electronics  card 
(output  data  stream) .  A  separate  bit-serial  data  trans¬ 
mission  stream  will  be  utilized  for  transmitting  input  in¬ 
formation  (analog  inputs,  discrete  inputs)  from  the  inter¬ 
face  electronics  to  the  master  controller  (input  data 
stream) . 

b)  The  subcontrollers  should  also  provide  the  following  func¬ 
tions  : 

1)  Word  framing 

2)  Input  output  data  stream  coordination 

3)  Block  address  identification  functions 

4)  Transmission  line  signal  boost  functions 

c)  In  each  subcontroller  provided,  it  should  be  possible  to 
mount  up  to  16  interface  electronics  cards. 
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11.2.7.5.3  Interface  Electronics  Card  Functions 

a)  The  interface  electronics  cards  should  have  three  interface 
ports  which  operate  as  follows: 

1)  The  output  port  should  connect  directly  to  the  simulated 
instrument,  switches,  etc. 

2)  The  power  port  should  connect  to  all  simulator  power 
buses  required  to  operate  the  instruments  and  the  cir¬ 
cuitry  on  the  interface  electronics  cards. 

3)  The  I/O  data  port  should  connect  to  the  subcontroller 
and  pass  all  the  digital  data  involved  to  and  from  the 
subcontroller . 

b)  The  interface  electronics  cards  should  also  incorporate 
closed-loop  test  circuitry  to  connect  appropriate  data 
conversion  modules  (including  associated  multiplex  data 
steering  gates  and  level  translators)  to  the  I/O  data  port 
for  the  closed-loop  test  checkout  of  the  interface  system. 

c)  The  following  capabilities  should  be  provided  on  the  inter¬ 
face  electronics  cards  as  needed: 

1)  Digital-to-analog  conversion:  11  bits  (10  magnitude 
bits  plus  sign  bit)  with  a  +10- volt  output  range 

2)  Analog- to-digital  conversion:  12  bits  output  with  a 
+10 -volt  input  range. 

3)  Discrete  inputs:  capable  of  accepting: 
o  +5  vdc  signal 

o  +28  vdc  signal 

o  Relay  or  digital  ground  with  1  mA  sinking  capability 

4)  Discrete  outputs: 

o  Digital  ground  with  10  mA  current  sink  and  28  vdc 
standoff 

o  Relay  ground  with  300  mA  current  sink  and  28  vdc 
standoff 

11.2.8  FCIS-LM  Computer  Program  Development.  The  .FCIS-LM 
computer  program  system  should  be  designed  as  a  group  of  modu¬ 
lar  subprograms.  The  software  to  be  provided  includes  the 
real-time  operational  programs  required  for  normal  trainer  op¬ 
eration,  and  off-line  programs  for  simulation  support,  computer 
system  support,  maintenance  and  test,  calibration  test,  and 
utility  programs. 


11-86 


11.2.8.1  Program  Module  Architecture.  Top-down  programming 
concepts  should  be  used  in  the  design  and  development  of  soft¬ 
ware  model  programs.  Top-down  programming  requires  that  cod¬ 
ing,  compiling,  checkout,  and  integration  of  program  modules 
and  submodules  be  performed  in  levels,  i.e..  Level  1  is  pro¬ 
duced  and  verified  before  Level  2  is  started,  etc.  The  primary 
difference  between  this  design  procedure  and  procedures  common¬ 
ly  used  in  software  development  is  that  development  phases 
(levels)  descend  instead  of  ascend,  i.e.,  common  practice  em¬ 
ploys  bottom-up  development.  Top-down  programming  requires 
that  each  successive  model  be  identified  and  the  contents  of 
the  programs  at  that  level  be  established  along  with  all  inter¬ 
faces  to  other  levels  within  the  module.  Each  module  will  then 
be  further  subdivided  into  submodules  and,  finally,  into  math¬ 
ematical/data  conversion  library  subroutines  and  module  varia¬ 
ble  and  constant  data  pools. 

11.2.8.2  Program  Language.  The  higher  order  language  consid¬ 
ered  as  most  desirable  for  the  FCIS-LM  is  the  FORTRAN  language. 
As  much  real-time  programming  as  possible  should  be  done  in 
FORTRAN.  The  only  allowable  exceptions  are  the  following: 

a)  Portions  of  the  real-time  executive 

b)  Device  Handlers  for  I/O  Devices 

c)  Subroutine  libraries,  including  writeable  control  store 
portions 

d)  Portions  of  Record/Playback/Demonstration 

e)  Visual  interface  (to  allow  bit  packing! 

11.2.8.3  Real-Time  Computer  Program? Roqui remenfcs-  Real-time 
computer  programs  include  those  considered  as  executive  pro¬ 
grams,  synchronous  application  programs  which  simulate  the  ve¬ 
hicle  dynamics  and  vehicle  subsystems,  motion  system  programs, 
and  advanced  training  programs. 

A  table  providing  the  estimated  real-time  computer  time  and 
memory  requirements  for  the  FCIS-LM  was  shown  in  Table  11-6.  . 

These  estimates  have  been  used  as  a  basis  for  determining  the 
FCIS  computation  system  hardware  requirements. 
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11.2.8.3.1  Executive  Programs.  A  set  of  modules  are  required 
which  constitute  the  supervisor,  or  real-time  executive,  pro¬ 
gram. 

Supervisor  Program  -  The  supervisor  program  will  include  a  mas¬ 
ter  control  function  to  provide  synchronization  among  simula¬ 
tion  module  execution,  interface  equipment  input/output  opera¬ 
tions,  frame  and  cycle  time,  verification,  background  activi¬ 
ties,  and  intercomputer  communication  and  synchronization.  The 
basic  timing  will  be  controlled  by  a  programmable  real-time 
clock  or  the  60  Hz  line  frequency  clock. 

!  The  definition  of  the  modules  to  be  executed  in  each  of  the 
|  computational  frames,  and  the  relative  order  of  execution  of 
j  these  modules,  will  be  fixed  by  a  queue  or  list  which  will  re¬ 
side  in  each  computer  core  memory.  The  primary  supervisor 
module  is  therefore  a  list-driven  processor  which  calls  each 
j  simulation  module  in  order,  after  a  start-of -frame  is  defined 
;  by  receipt  of  an  external  interrupt. 

Other  processing  will  be  provided  by  modules  within  the  super¬ 
visor  program  group.  Significant  processing  provided  on  an  on- 
demand  basis  includes  executive  trap  processing,  basic  real- 
time/non-real-time  mode  control,  and  control  of  operator  con¬ 
sole  input/output  as  related  to  supervisor  program  control. 

The  real-time  executive  will  control  the  execution  of  the  sim¬ 
ulation  software.  It  will  consist  of  a  single  task  and  will: 

a)  Be  interrupted  by  interrupt  handlers  within  the  same  task 
at  specified  time  intervals  for  determining  out-of-time 
conditions  and  starting  hardware  functions  on  a  periodic 
basis. 

b)  Control  execution  of  simulation  modules 

c)  Control  simulation  mode  from  the  master  CPU 

d)  Perform  frame  and  cycle  timing 

e)  Process  error  messages 

f)  Schedule  synchronous  and  asynchronous  tasks 


g)  Allow  modules  to  activate  or  deactivate  other  modules 


h)  Allow  interrupts  to  enable  the  scheduling  of  on-demand 
modules 

i)  Keep  all  computers  in  a  multiprocessor  complex  in  sync 
while  running  in  an  integrated  (master/slave'  state. 

I/O  requests  are  initiated  via  subroutines.  This  will  permit 
user  software  to  be  written  with  I/O  requests  that  are  trans¬ 
parent  to  the  actual  I/O  driver  requests. 

The  capability  will  be  provided  to  reserve  a  portion  of  each 
frame  for  background  processing.  Background  processing  will 
reside  in  the  spare  time  and  memory  within  the  simulation  com¬ 
plex. 

Overlay  Loader  -  Overlays  will  be  supported  by  the  supervisor 
programming  system.  Support  software  will  be  used  to  define 
the  overlay  structure  and  will  build  the  task  with  overlays . 
These  overlay  structures  will  be  capable  of  dealing  with  code 
or  data. 

Slave  Real-Time  Monitor  -  A  slave  real-time  monitor  will  be 
developed  to  run  in  the  slave  computers  in  the  multiprocessor 
complex.  It  will  perform  basically  the  same  function  as  the 
executive  in  the  master  computer.  This  will  allow  the  develop¬ 
ment  of  one  set  of  real-time  utility  programs  for  both  mas¬ 
ter  and  slave  computers.  The  size  will  be  kept  to  a  minimum 
and  the  program  will  be  coded  in  assembler  language. 

The  functions  of  the  slave  real-time  monitor  will  be: 

a)  Limited  task  switching  -  multiple  tasks  will  be  allowed 
only  in  foreground  with  no  background. 

b)  Intercept  all  disk  I/O  requests  and  route  them  through  the 
shared  memory  of  the  master  computer. 

c)  Capability  of  adding  special  I/O  drivers  by  same  means 
used  by  the  vendor's  real-time  monitor. 

Math  Libryy  -  A  library  of  mathematical  procedures  will  be 
maintained  under  the  non-real-time  disk  operating  system.  A 
numerical  integration  routine ,  together  with  such  standard  pro¬ 
cedures  as  limits ,  functions  interpolation,  and  trigonometric 
functions,  will  be  included.  The  system  generation  software 
will  automatically  include  a  single  copy  of  each  required  rou¬ 
tine  and  perform  the  necessary  linkage  resolution  at  generation 
time.  Thus,  the  real-time  software  will  include  a  single  copy 
of  each  referenced  routine.  Calling  conventions  will  be  com¬ 
patible  with  FORTRAN  and  uniform  between  routines. 


I/O  Programs  -  Handler  subroutines  will  be  provided  for  all 
devices  used  in  the  real-time  simulation  environment,  including 
signal  conversion  equipment,  operator's  console,  instructor 
station  CRT/keyboard,  magnetic  disk,  magnetic  tape,  and  real¬ 
time  clock. 

These  I/O  handlers  may  be  broken  into  three  basic  types: 

a)  The  signal  conversion  equipment  handler,  which  is  a  list- 
driven  subroutine  wherein  the  receipt  of  each  I/O-complete 
interrupt  initiates  start  of  a  new  I/O  transfer,  and  the 
list  of  different  transfers  to  be  affected  during  a  frame 
is  preassembled  and  constant  during  the  entire  simulation. 

b)  The  moving-head  disk  handler,  in  which  successive  requests 
for  I/O  are  queued  in  a  priority  code  order,  and  receipt 
of  an  I/O-complete  interrupt, causes  immediate  handling  of 
the  next  request  in  the  queue,  if  one  exists. 

c)  All  other  peripheral  handlers,  which  handle  I/O  requests 
on  a  one-at-a-time  basis. 

Real-Time  Interface  Equipment  Diagnostic  Program  (Fault  Isola¬ 
tion  System  Support  -  A  real-time  closed- loop  simulator  linkage 
(interface)  test  will  be  provided  to  locate  and  isolate  fail¬ 
ures  in  the  signal  conversion  equipment  (SCE) .  The  program  will 
perform  an  automatic  checkout  of  the  interconnection  between 
the  computer  and  the  simulator  instrumentation.  The  diagnostic 
will  reside  on  disk  and  tape  and  will  be  designed  to  operate 
off-line  or  in  real-time  (background  mode)  as  a  Built-In  Test 
Function  Program. 

The  SCE  consists  of  the  following  four  basic  electronic  hard¬ 
ware  components,  each  having  its  own  special  test  routines: 

a)  A  master  controller  which  interfaces  with  the  computer, 
performs  its  own  processing  functions,  and  distributes 
data  to/from  the  system  components. 

b)  The  master  controller  output  port  bus, over  which  the  data 
is  transferred. 

c)  Subcontroller  which  provides  the  interface  between  the 
master  controller  and  the  actual  system  cards. 

d)  System  cards  which  interface  with  the  simulated  systems. 

Like  the  interface  hardware,  the  program  itself  will  function 
in  a  modular  manner.  Among  the  principal  tests  to  be  performed 
are: 

1)  A  data  pattern  and  addressing  test  of  the  master  control¬ 
ler  memory 
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2)  A  test  of  the  floating-point  conversion  hardware. 

3)  A  closed-loop  test  of  individual  system  card  performance 
using  a  group  of  hardware  subsystems  contained  within  the 
master  controller.  These  tests  include: 

a)  Testing  discrete  inputs  and  digital  word  inputs  at  both 
logic  states 

b)  Testing  discrete  outputs  and  digital  word  outputs  at 
both  logic  states. 

c)  Testing  analog  inputs  over  the  entire  analog  range  for 
the  ability  to  respond  to  a  computer-controlled  test 
value  within  a  predetermined  tolerance. 

4)  A  test  of  proper  functioning  of  the  DMA  channel  if  a  fail¬ 
ure  is  encountered  in  any  of  the  above  tests.  An  appro¬ 
priate  error  message  will  be  output  on  a  hardcopy  unit 
giving  the  type  and  hardware  location  of  each  failure. 

11.2.8.4  Off-Line  Programs.  Off-line  programs  include: 

o  Simulation  support  programs 

o  Computer  system  support  programs 

o  Maintenance  and  test  programs 

o  Calibration  test  programs 

o  Utility  support  programs 

11.2.8.4.1  Simulator  Support  Programs. 

Cycle  Time  Verification  Programs  -  Programs  are  required  to  ver¬ 
ify  the  operational  cycle  time  and  spare  time  remaining  within 
the  cycle  and  frame  periods,  and  to  preflight-check  the  simula¬ 
tor.  These  verification  programs  should  be  designed  to  run 
within  the  deliverable  computer  configuration. 

Premission  Check  Program  -  A  computer  program  is  required  to 
support  the  operation  of  the  simulator  in  the  normal  procedures 
identified  for  premission  check.  This  program  should  easily 
determine  if  the  simulator  is  ready  for  operation.  It  should 
operate  at  normal  iteration  rates  and  generate  a  sequence  of 
standard  outputs  which  drive  all  perceivable  outputs  and  recog¬ 
nize  all  inputs.  The  sequence  of  outputs  should  be  cyclic, 
with  provisions  to  stop  the  sequence  at  any  of  the  standard 
output  values.  The  complete  premission  check  procedure  using 
this  program  should  not  exceed  15  minutes.  This  is  not  intend¬ 
ed  as  a  calibration  program,  but  rather  as  a  quick  system 
operational  check. 
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Mission  Support  Programs  -  A  mission  support  program  for  alpha¬ 
numeric/graphic  CRT  display  generation  is  required  to  operate 
on  the  FCIS  computational  system. 

The  CRT  page  generator  should  accept  source  input  in  card  image 
format  (cards  or  tape) ,  perform  syntax  checking,  generate  the 
display  skeleton  (static  information)  and  conversion  attribute 
data  (for  dynamic  information) ,  and  store  these  in  the  on-line 
loadable  CRT  page  file.  The  page  generator  should  produce  a 
hardcopy  listing  of  the  page  content,  errors,  and,  optionally, 
the  object  data. 

11.2.8.4.2  Computer  Program  System  Support  Programs.  Support 
programs  are  required  to  facilitate  computer  program  generation, 
redesign,  update,  modification,  error  correction,  and  other 
support  functions.  The  support  programs  to  be  provided  are  as 
follows: 

Operating  System  (OS) 

a)  A  computer  vendor-supplied  real-time  operating  system 
should  be  used  to  provide  a  high-performance  multiple  task 
environment  for  batch  oriented  processing.  The  OS  shall 
be  responsible  for  the  total  programming  system  management. 
All  support  programs  should  be  programmed  to  operate  under 
the  control  of  the  OS  and  utilize  the  services  it  provides, 
while  remaining  as  independent  of  modification  to  the  OS 

as  possible. 

b)  The  real-time  operating  system  should  provide  a  multi-task¬ 
ing  environment  for  user-development  application  systems. 

It  should  be  optimized  to  the  requirements  of  event-driven 
real-time  systems. 


c)  Program  preparation  and  development  should  be  supported 
and  carried  out  in  parallel  with  the  operation  of  a  real¬ 
time  system. 

d)  The  operating  system  should  provide  a  flexible  structure, 
enabling  systems  designers  to  construct  systems  optimized 
for  their  individual  applications,  based  on  a  modular  exe¬ 
cutive,  intertask  coordination,  and  control  of  task  capa¬ 
bilities. 

e)  The  interrupt  handling  facilities  required  include 
dynamic  task  priorities,  task-handled  traps,  and  real-time 
scheduling . 

f)  A  data  management  system  is  required  which  incorporates 
the  following  features: 


o  Device  Independence 


o  Named  Files  and  Devices 


o  File  and  Device  Protection 
o  Contiguous  and  Chained  File  Structures 
o  Disk  Pack  Interchange 

g)  General  supervisory  services,  including  clock  and  calendar 
facilities,  character  manipulation  facilities,  priority 
semaphores,  and  a  memory  manager  should  be  provided.. 

h)  User  interfaces.  Comprehensive  preparation  facilities 
should  include  support  of  assemblers,  compilers,  utilities, 
task  establisher,  and  configuration  utility  program. 

Peripheral  Operating  System 

a)  A  complete  set  of  standard  I/O  handlers  are  required  to 
execute  under  control  of  the  OS.  These  handlers  may  also 
be  invoked  by  user  programs  under  supervisory  services 
provided  with  the  real-time  operating  system.  The  drivers/ 
handlers  selected  to  be  supplied  for  the  FCIS  computer  con¬ 
figuration  should  include  those  to  support  the  following 
devices  s 

o  Card  Reader 

o  Line  Printer 

o  80 -MB  Disk 

o  Magnetic  Tape  Unit 

o  CRT/Keyboard 

o  Hardcopy  unit 

o  Real-Time  Clock 

b)  Other  special  I/O  interface  handlers  should  be  provided  as 
required  to  be  included  as  part  of  the  real-time  simulation 
executive  program.  These  handlers  should  be  compatible 
with  the  OS  while  retaining  those  special  characteristics 
demanded  by  the  simulation  equipment. 

Loaders,  Assemblers,  and  Compilers 

a)  The  loader  program  provided  as  part  of  the  OS  should  be 
the  primary  processor  for  building  the  real-time  simulation 
load.  A  set  of  job  control  statements  should  be  provided 
to  allow  complete  CPU-by-CPU  loads  to  be  accomplished  with 
a  minimum  of  operator  intervention,  using  operating  system 
services  for  file  and  data  management. 


b)  To  provide  for  automatic  handling  of  the  large  number  of 
data  pool  variable  names  anticipated  and  to  provide  auto¬ 
matic  library  call  facilities ,  a  data  pool  symbol  diction¬ 
ary,  an  associated  file  maintenance  program,  and  an  object 
module  editor  program  are  required.  The  dictionary  and 
editor  should  provide  an  optimum  environment  for  the  load¬ 
er  to  generate  the  relatively  large  load  required  (compar¬ 
ed  to  most  user  programs  which  are  loaded  to  run  under  the 
OS) . 

c)  A  bootstrap  loading  subroutine  should  be  incorporated  into 
the  real-time  simulation  load  in  absolute  form.  Standard 
checksum  facilities  of  the  loader  shall  be  used  for  check¬ 
ing  the  validity  of  the  relocatable  object  modules.  Other 
configuration  control  related  features  that  are  available 
as  by-products  of  the  loader  should  include  a  hardcopy 
output  of  a  load  map  containing  a  list  of  all  modules 
loaded,  their  locations  in  memory  relative  to  the  start 

of  the  task,  all  external  symbols  with  a  cross-reference 
to  their  use  in  the  program  modules  and  header  information 
contained  in  the  load  file  and  reproduced  on  hardcopy, 
giving  the  time  and  date  of  the  load,  its  revision  level, 
and  other  identifying  characteristics. 

Memory  Dump  -  A  computer. vendor  supplied  memory  dump  program 
should  be  provided  to  output  the  contents  of  a  section  of  mem¬ 
ory  defined  by  a  set  of  address  limits.  The  format  of  the 
dump  should  be  selectable  and  include  the  following: 

a)  Binary 

b)  Character 

c)  Double-precision  floating-point 

d)  Single-precision  floating-point 

e)  Pull-word  decimal 

f)  Half-word  decimal 

g)  Half-word  hexadecimal 

h)  Full-word  hexadecimal 
Mathematical  Library 

a)  The  FORTRAN  system  consists  of  a  compiler  and  a  FORTRAN 
library.  In  addition  to  providing  subroutines  for  all 
supervisor  functions  whose  calls  are  generated  by  the  com¬ 
piler  and  run-time  (under  the  operating  system)  diagnostic 
messages,  this  FORTRAN  library  should  contain  a  set  of 
mathematical  routines  that  include,  standard  FORTRAN  func¬ 
tions  as  a  subset.  This  FORTRAN  system  should  be  access!- 


ble  to  both  real-time  application  programs,  and  verifica¬ 
tion  and  support  programs  which  run  under  the  OS. 

b)  The  real-time  simulation  load  should  include  a  specially 
written  set  of  mathematical  subroutines,  existing  as  one 
or  more  modules  to  be  incorporated  into  the  load  for  each 
CPU.  These  subroutines  should  include  assembler  language 
programs  and  mathematical  subroutines  which  require  less 
execution  time  than  similar  subroutines  provided  in  the 
standard  FORTRAN  library  package.  Other  subroutines  should 
be  provided  for  data  conversion  tasks  which  are  peculiar 

to  t:he  real-time  simulation  tasks,  and  should  also  include 
conversions  from  internal  memory  storage  formats  to  print 
and  CRT  terminal  display  formats,  and  conversion  from  key¬ 
board  formats  to  internal  processing  formats. 

c)  The  complete  set  of  these  special  mathematical  and  data 
conversion  subroutines  should  be  provided  in  source  and 
relocatable  object  module  formats,  in  a  form  which  may  be 
used  for  real-  time  simulation  or  operation  under  the  OS. 

Copy  and  Trace  Routines  -  The  following  general-purpose  develop¬ 
ment  tools  should  be  provided  as  part  of  the  software  to  oper¬ 
ate  under  control  of  the  OS: 

a)  A  background  program  which  gives  the  user  trace,  break¬ 
point,  and  snapshot  features. 

b)  A  terminal  oriented  text  editor  which  allows  the  user  to 
interactively  create  source  images  for  submission  to  the 
system. 

c)  A  utility  which  allows  the  user  to  copy  files  from  one  de¬ 
vice  to  another  for  peripheral  conversion,  reproduction  or 
data  retention. 

d)  Under  the  operating  system  it  should  be  possible,  using 
existing  job  control  files,  to  copy  ASCII  or  binary  files 
from  device  to  device,  including  disk  to  disk,  card  reader 
to  disk,  disk  to  printer,  card  reader  to  printer,  disk 

to  tape,  tape  to  disk,  and  tape  to  tape. 

11.2.8.4.3  Maintenance  and  Test  Programs.  Programs  are  re¬ 
quired  to  fully  test  the  operation  of  both  the  computational 
hardware  system  and  the  interface  equipment.  When  a  malfunc¬ 
tion  occurs  in  the  computers  or  simulator  equipment,  these  pro¬ 
grams  should  provide  information  to  the  operator  to  identify 
and  locate  the  malfunction.  They  should  be  capable  of  running 
with  a  minimum  of  operator  intervention. 

Real-Time  Interface  Equipment  Diagnostics 

a)  The  maintenance  procedure  should  allow  the  operator  to 
localize  real-time  interface  errors  detected  during  Pre- 
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mission  Check  or  during  training  sessions.  A  master  hard¬ 
ware  index  should  be  available  on  the  disk  for  display  on 
the  DEBUG  CRT.  It  shall  contain  the  panel  numbers  and  a 
brief  description  of  each  panel. 

b)  Three  unique  test  cases  for  each  panel  should  test  all  the 
panels'  components.  These  tests  should  be  automatically 
cycled  through  as  many  times  as  required  or  the  operator 
should  be  able  to  specify  each  new  test  case  manually. 

When  the  operator  knows  which  panel  contains  the  fault,  he 
should  be  able  to  traverse  the  assembly  tree  to  the  desired 
test  page. 

c)  After  the  operator  locates  the  panel  to  be  tested,  all  SCE 
equipment  should  be  tested  in  an  orderly  fashion.  All  of 
the  DI's,  DO's,  AI's  and  AO's  should  be  displayed  on  the 
CRT  screen  with  their  associated  documentation,  including 
symbol,  description,  system  drawing,  linkage  designation, 
and  appropriate  input  position  or  readout  value.  Inputs 
should  have  the  actual  and  expected  values  displayed  to¬ 
gether.  Outputs  should  have  the  actual  drive  value  and  a 
line  number  for  modifying  the  value. 

Computer  Diagnostics  -  A  complete  set  of  vendor-supplied  com¬ 
puter  diagnostics  are  required.  These  diagnostics  should  in¬ 
clude  but  not  be  limited  to  the  followings 

a)  Memory  diagnostic 

b)  CPU  diagnostics 

c)  Disk  diagnostics 

d)  Printer  diagnostics 

e)  Disk  Formatters 

f)  System  exercisers 

g)  Card  reader  diagnostics 

h)  MTU  diagnostics 

11.2.8.4.4  Calibration  Test  Programs. 

a)  Calibration  test  programs  are  required  to  check  the  accur¬ 
acy  and  flow  of  signals,  both  statically  and  dynamically, 
through  the  full  range  of  variables,  between  the  computer 
and  all  signal  sources  and  terminal  points.  This  program 
should  also  be  used  to  calibrate  the  interface  equipment, 
displays  and  controls,  and  to  determine  whether  the  inputs 
provided  by  the  simulation  program  are  being  transmitted 
properly  to  the  ultimate  destination. 


It  should  initialize  all  signal  paths  (both  source  to 
computer  to  terminal  points)  to  preselected  values  and 
allow  monitoring  of  the  signal  and  subsequent  calibration 
at  any  point  in  the  signal  path  where  the  signal  can  be 
monitored.  The  program  should  allow  the  operator  to  tem¬ 
porarily  modify  the  preselected  values  on-line. 

b)  Each  hardware  panel  should  be  provided  with  three  unique 
test  cases  for  the  testing  of  all  components.  These  should 
be  automatically  cycled  through  as  many  times  as  required, 
or  the  operator  shall  be  able  to  specify  each  new  test 
case  manually.  Calibration  of  all  analog  devices  should 
be  performed  using  prescribed  values  generated  off-line 
and  stored  on  the  disk.  To  insure  that  analog  instruments 
are  driven  smoothly,  a  ramp  test  shall  be  included  in 
order  to  cycle  the  instruments  from  their  minimum  to  maxi¬ 
mum  values  in  finite  steps.  The  increments  should  be 
specified  off-line  and  the  instruments  should  be  driven 
at  the  same  execution  rate  as  the  operational  modules. 

11.2.8.4.5  Utility  Support  Programs 

Assembler  Program  -  An  assembler  is  required.  However,  for  the 
FCIS-LM,  assembler  language  programs  should  be  restricted  to 
those  programs  requiring  language  facilities  not  available  in 
a  higher-level  compiler.  These  programs  consist  mostly  of  in¬ 
terrupt  and  trap  handlers,  I/O  handlers,  and  programs  which  de¬ 
mand  a  high  degree  of  space  and  time  optimization.  The  assem¬ 
bler  should  be  designed  to  operate  in  conjunction  with  the  real 
time  operating  system. 

The  assembler  should  provide  flexibility  in  field  formatting 
and  provides  a  segmented  object  code  to  be  used  with  a  32-bit 
processor.  A  fully  annotated  cross-reference  of  symbolics  and 
error  references  is  required.  The  assembler  should  allow  8- 
character  alphanumeric  symbols.  In  addition,  a  set  of  pseudo¬ 
operations  should  be  available  to  the  user.  FORTRAN  common 
block  definition  and  data  pool  referencing  should  also  be  pro¬ 
vided.  The  assembler  should  function  in  a  two-pass  environment 
with  additional  passes  to  "squeeze"  (optimize)  the  code  to  pro¬ 
duce  the  most  efficient  code  possible. 


FORTRAN  Compiler 


a)  The  basic  programming  language  to  be  used  for  the  FCIS 
simulation  software  should  be  FORTRAN.  A  precompiler  to 
scan  the  FORTRAN  source  code  and  automatically  generate 
external  references  to  a  common  data  pool  is  also  required. 
In  addition,  a  cross  reference  between  the  symbol  diction¬ 
ary  (data  pool  dictionary)  and  the  source  modules  should 
be  produced  and  saved  on  the  disk  as  part  of  the  configu¬ 
ration  control  system. 
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b)  The  basic  structure  of  the  FORTRAN  compiler  should  conform 
to  ANSI  FORTRAN  Standard  X3. 9-1966.  The  compiler  should 
be  designed  to  be  used  with  the  operating  system.  The 
compiler  should  accept  a  mix  of  FORTRAN  statements  and  in¬ 
line  assembly  code.  With  the  FORTRAN  system  it  should  be 
possible  to  have  program  and  data  sizes  up  to  1  megabyte. 
The  FORTRAN  repertoire  should  include  mixed-mode  arithme¬ 
tic  operation,  Hollerith  constants,  and  string  data  state¬ 
ments  that  allow  array  initialization,  multiple  entry  sub¬ 
routines,  and  error  and  end-of-file  returns  from  read- 
write  operations.  Real-time  extensions  are  required  such 
as  bit  and  byte  manipulation  of  integers,  including  Inclu¬ 
sive  OR,  Logical  Product,  Logical  Complement,  Exclusive 
OR,  Logical  Shift,  Bit  Test,  Byte  Load  and  Store,  Byte 
Clear,  and  Byte  Complement.  The  FORTRAN  Library  routines 
should  be  reentrant  to  minimize  memory  requirements  in  a 
real-time  environment.  Extensive  error  checks  should  be 
performed  during  the  compilation  and  assembly  processes 
with  error  flag  notation  on  outputs. 

Trace  Routines  -  Software  should  be  provided  to  enable  the  user 
to  follow  the  execution  of  a  program  through  the  continuous 
listing  of  the  location  counter,  the  hexadecimal  representa¬ 
tion  of  the  instructor,  the  instruction  mnemonic,  and  the  oper¬ 
ands  of  the  instruction,  to  the  printer  or  other  device.  A 
branch  trace  should  also  be  provided  which  lists  the  value  of 
the  location  counter  only  if  a  branch  instruction  is  encountered 
and  taken. 

Simulator  Verification  Programs  -  Software  should  be  provided 
which  allows  the  user  to  check  out  his  software  in  the  single 
module  mode  or  grouped  as  part  of  a  system.  The  operator  should 
be  able  to  select  the  module  to  be  tested  from  a  CRT  index. 

The  module  should  then  be  exercised  through  prestored  test 
cases  designed  to  investigate  all  paths  through  the  module,  in¬ 
cluding  the  longest  path  and  the  path  using  the  greatest  amount 
of  CPU  time.  The  printer  should  be  used  for  hardcopy ing  the 
CRT  display,  exception  reporting,  and  as  an  X-T  recorder.  Dur¬ 
ing  this  test, all  debug  capabilities,  such  as  breakpoints, 
traces,  and  snapshots,  should  be  available.  Therefore,  the 
module  is  in  the  same  environment  it  will  encounter  as  part  of 
the  simulator  load.  As  an  option,  the  capability  should  be 
provided  to  set  input  parameters  before  the  execution  of  any 
module  and  to  examine  the  results  after  the  exception  of  the 
same  or  any  other  module,  thus  allowing  entire  systems  or  groups 
of  modules  to  be  exercised.  This  option  should  be  "usable” 
interactively  via  the  CRT  system.  It  should  provide  a  means 
to  test  a  module  in  an  integrated  mode  before  it  becomes  part 
of  the  operational  load. 


Data  Base  Support  Programs 


a)  Computer  programs  used  to  design  and  implement  operational 
data  bases  are  required  to  facilitate  modification  to 
these  data  bases.  Computer  programs  used  to  perform  data 
reduction  to  tabular i zed  and/or  stored  data  should  be  pro¬ 
vided.  These  programs  should  be  written  for  execution  on 
the  computational  system  configuration  designed  for  the 
simulator  site. 

b)  In  order  to  control  and  maintain  the  data  base,  a  Data 
Base  Generation  System  (DBGS)  software  package  should  be 
provided.  The  DBGS  should  perform  a  multi-CPU  complex  in 
one  symbol  dictionary.  This  system  should  perform  modifi¬ 
cation  to  the  symbol  dictionary  by  addition,  deletion,  or 
change  of  variable  definition.  Variables  and  I/O  should 
be  allocated  into  the  symbol  dictionary  automatically  by 
the  system. 

c)  Listings  of  the  symbol  dictionary  should  be  generated  in 
alphabetic  order  of  variables  and  also  according  to  their 
relative  location  in  memory.  A  relative  listing  should 
indicate  spare  locations  and  all  overlays  and  equivalences 
of  variables. 

d)  Configuration  control  information  such  as  cross-reference 
listings  (concordance)  should  be  provided  by  the  DBGS. 

Simulation  System  Update  and  Modification  Programs  -  A  program 
should  be  provided  to  efficiently  edit  the  source code  in  order 
to  maintain  CPS  configuration  control  and  to  support  CPS  modi¬ 
fication  and  update.  Disk  source  images  should  be  usable  as  the 
baseline  source  code  media.  This  procedure  should  support  se¬ 
lective  module  editing,  compiling/assembling,  linking,  and  test¬ 
ing.  It  should  be  usable  by  simulator  maintenance  technicians. 
The  input  device  for  change  information  should  be  the  remote 
CRT  terminal  keyboard/cassette  magnetic  tape  system. 

a)  Source  Update  -  The  Source  update  Program  (UPDATE)  should 
allow  the  user  to  edit  card  image  source  file  from  the 
desk.  The  edit  should  be  performed  by  control  functions 
(insert,  add,  replace,  delete)  based  on  statements/numbers 
contained  in  columns  77-80  of  the  card  image  records.  The 
following  features  are  required: 

o  Automatic  configuration  control  of  header  information, 
revision  level,  and  change  control 

o  Compressed  storage  on  disk 

o  Error  protection 

o  Statement  level  change  control 
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o  Full  listing  with  change  indicated 
o  Resequencing  option 

o  Edit  back  to  any  previous  revision  level 

b)  Source  Modification  -  A  source  modification  program  (SCAN) 
is  required  to  connect  the  user's  source  statements  with 
the  common  data  pool.  It  should  not  be  necessary  for  the 
user's  (programmer ' s)  code  to  contain  data  declarations 
(TYPE,  DATA,  DIMENSION  or  COMMON  STATEMENTS) .  SCAN  shall 
search  the  source  code,  locate  all  variables  stored  or 
used,  find  definitions  for  these  variables  in  the  symbol 
dictionary,  and  add  the  required  data  declarations  to  the 
source  prior  to  compilation  and  assembly. 
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